You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now it can be difficult to spell out types where we care about e.g. the third type parameter but not the rest. The unary <:T syntax (#6984) makes this easier, but there's still the footgun that the user needs to know the correct constraint for the given parameter upfront if they want to correctly express a subtype, e.g.
julia>struct Foo{T<:Number} end# just dropping around `<:Any` everywhere you don't care about a parameter won't work
julia> Foo{<:Any} <:Foofalse
It would be super nice if we could just place _ in type parameters lists for parameters we don't care about, and they'd expand to the appropriate where clause, e.g.
struct Bar{A<:Number,B<:Number,C<:Tuple{A,B}} end
Bar{_,Integer,_} # expands to Bar{A,B,<:Tuple{A,B}} where {A<:Number,B<:Integer}
I think there could be very easy rule for unambiguously picking the scope of the _ bindings, I'd probably just go with "the closest where clause to the usage", e.g.
Vector{Bar{_,Integer,_}} # expands to Vector{Bar{A,B,<:Tuple{A,B}} where {A<:Number,B<:Integer}}
AFAICT, actually implementing this is not a simple task by any means, since it would probably also entail fixing a bunch of other issues w.r.t. automatically enforcing/propagating implicit constraints for where parameters. For this to even be a 1.0-compatible feature (i.e. not considered breaking), we'd have to also treat #30162 as a bug (but it's marked "bug" already so I guess that's that). Hmmm...is there any other breakage this could cause?
This proposal also probably conflicts with #24990, but I really dislike that use of our bitbucket syntax anyway so that's fine by me 😁 (👍from @ararslan in 3, 2, 1...). Obviously we could pick a different syntax than _ for this regardless, I just like _ here because it feels consistent with its use in the value domain.
The text was updated successfully, but these errors were encountered:
I definitely like this. It also jives well with the general pattern of using _ to mean "I don't care about this," e.g. in _, _, x = thingthatreturnsthreethings().
The underscore syntax and auto-constraining parameters (#6383) are IMO totally orthogonal issues. I think we should apply auto-constraining as widely as we dare no matter what. Underscore syntax can be decided separately.
IIUC, this puts the wheres outside all types, which would be different from <:T, which puts where outside only a single type. I understand the motivation for that but it's a bit of a gotcha.
Right now it can be difficult to spell out types where we care about e.g. the third type parameter but not the rest. The unary
<:T
syntax (#6984) makes this easier, but there's still the footgun that the user needs to know the correct constraint for the given parameter upfront if they want to correctly express a subtype, e.g.It would be super nice if we could just place
_
in type parameters lists for parameters we don't care about, and they'd expand to the appropriatewhere
clause, e.g.I think there could be very easy rule for unambiguously picking the scope of the
_
bindings, I'd probably just go with "the closestwhere
clause to the usage", e.g.Vector{Bar{_,Integer,_}} # expands to Vector{Bar{A,B,<:Tuple{A,B}} where {A<:Number,B<:Integer}}
AFAICT, actually implementing this is not a simple task by any means, since it would probably also entail fixing a bunch of other issues w.r.t. automatically enforcing/propagating implicit constraints for
where
parameters. For this to even be a 1.0-compatible feature (i.e. not considered breaking), we'd have to also treat #30162 as a bug (but it's marked "bug" already so I guess that's that). Hmmm...is there any other breakage this could cause?This proposal also probably conflicts with #24990, but I really dislike that use of our bitbucket syntax anyway so that's fine by me 😁 (👍from @ararslan in 3, 2, 1...). Obviously we could pick a different syntax than
_
for this regardless, I just like_
here because it feels consistent with its use in the value domain.The text was updated successfully, but these errors were encountered: