<FromGitter>
<HertzDevil> currently the first overload is ordered before the second, but the new (wip) algorithm works by comparing type restrictions before considering things like default args, so the second comes first
<FromGitter>
<HertzDevil> because whatever is passed as the first positional argument will match `obj` and `*objects : _`, and having a restriction is stricter than not having one
<FromGitter>
<HertzDevil> this means the second overload cannot itself call the first one, unless `obj` is passed as a named arg
<FromGitter>
<Blacksmoke16> if it didnt have `: _` would they just be in order of def i assume?
<FromGitter>
<HertzDevil> in that case every valid call for the first overload is also a valid call for the second call (i.e. 1 arg), but not vice-versa; therefore the splat-less one will come first
<FromGitter>
<Blacksmoke16> π
<FromGitter>
<HertzDevil> a fix is to *also* put `: _` for the first overload, another is to write the second like `obj, *rest`
<FromGitter>
<HertzDevil> this also happens to `Object#in?`
<FromGitter>
<HertzDevil> so perhaps it's not that much of an edge case because `Object` and `_` match pretty much everything...
<FromGitter>
<Blacksmoke16> is `_` more or less specific than `Object`?
<FromGitter>
<HertzDevil> `Object` is more specific because it doesn't accept `Void`
<FromGitter>
<HertzDevil> btw both accept `NoReturn`
<FromGitter>
<Blacksmoke16> gotcha
<FromGitter>
<HertzDevil> at top-level they're pretty much the same because you shouldn't deal with raw `Void` anyway, but `Pointer(Void)` will match `Pointer(_)`, not `Pointer(Object)`
<FromGitter>
<HertzDevil> due to the way AST node restrictions work
<FromGitter>
<HertzDevil> the fix so far has broken only one compiler spec and that's a wording change in a "no overload matches" error message
<FromGitter>
<HertzDevil> still unclear about 1.x's backward compatibility guarantees though
<FromGitter>
<HertzDevil> > Language and standard library features wonβt be removed or changed in any way that could prevent existing code from compiling and working
aquijoule_ has joined #crystal-lang
richbridger has quit [Ping timeout: 252 seconds]
<FromGitter>
<HertzDevil> if methods like `IO#print` above require type restrictions on the splat-less overloads, does that constitute a breaking change that prevents existing code from compiling and working
DTZUZU_ has joined #crystal-lang
DTZUZU has quit [Ping timeout: 252 seconds]
DTZUZU has joined #crystal-lang
DTZUZU_ has quit [Ping timeout: 240 seconds]
DTZUZU_ has joined #crystal-lang
DTZUZU has quit [Ping timeout: 265 seconds]
_ht has joined #crystal-lang
hendursa1 has joined #crystal-lang
hendursaga has quit [Ping timeout: 240 seconds]
<yxhuvud>
How would the difference be shown in practice, in this case?
dostoyevsky has quit [Quit: leaving]
dostoyevsky has joined #crystal-lang
dostoyevsky has quit [Client Quit]
dostoyevsky has joined #crystal-lang
roswold has joined #crystal-lang
roswold has left #crystal-lang [#crystal-lang]
<FromGitter>
<ShalokShalom> How is Crystal's type system different from Hindley-Milner?
Nekka has quit [Read error: Connection reset by peer]
Nekka has joined #crystal-lang
<FromGitter>
<ShalokShalom> Why are "Constants" listed within 'Types and Methods' instead of 'Assignments?
<FromGitter>
<HertzDevil> thinking whether we could include both definitions of overload ordering, still use the old one, but emit a warning whenever the new and old orders don't agree
<FromGitter>
<HertzDevil> then 1.0.x and 1.1 would have the warning, and 1.2 will remove the old ordering
<FromGitter>
<HertzDevil> and we also patch `IO#print` snd `Object#in?` etc before 1.2
<FromGitter>
<ShalokShalom> https://ibb.co/4SYVGxr Variables are also assignments when they are local. Constants are also assignments when they are always part of a type. When somebody looks through your documentation, and they want to see if you support constants, they look under 'Assignment', and writing documentation based on how the user does access it, is the way to go, if you like to reach the audience. User documentation is
<FromGitter>
... something else than documentation for the people who work on the language, who are also interested in the implementation detail. You can still mention, in the constant article, that they are always part of a type.
<FromGitter>
<ShalokShalom> They are still assignments.
ua has quit [Ping timeout: 252 seconds]
ua has joined #crystal-lang
<FromGitter>
<ShalokShalom> Other than that, the language looks pretty good.
<FromGitter>
<Daniel-Worrall> Do you think there's a more efficient to turn an array (or enumerable/iterable) of digit Chars into an integer. I have `n.reduce(0) {|n, d| n * 10 + d.to_i}` right now
<FromGitter>
<Daniel-Worrall> `n = ['1', '2', '3']`, I want `123`
<FromGitter>
<oprypin:matrix.org> @Daniel-Worrall: no this seems like a very good approach
<FromGitter>
<Blacksmoke16> `n.join("").to_i`
<FromGitter>
<oprypin:matrix.org> if you're micro-optimizing, there are some safety checks in `Char#to_i` that you can avoid by writing just `d - '0'` instead
<FromGitter>
<Daniel-Worrall> Ooh
<FromGitter>
<Daniel-Worrall> Took me a moment to realise why that works
<FromGitter>
<HertzDevil> language features can probably emit similar warnings without `@[Experimental]`
_ht has quit [Remote host closed the connection]
<FromGitter>
<HertzDevil> like if that is to land as an experimental language feature, the compiler shouldn't refuse to warn the user just because a macro def itself isn't annotated with `@[Experimental]`