Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: use underscore to represent unused, but well-constrained, parameters in type parameter lists #30355

Closed
jrevels opened this issue Dec 11, 2018 · 6 comments
Labels
julep Julia Enhancement Proposal

Comments

@jrevels
Copy link
Member

jrevels commented Dec 11, 2018

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} <: Foo 
false

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.

@ararslan
Copy link
Member

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().

@StefanKarpinski
Copy link
Member

It does have a pleasantly uncontroversial feel to it.

@ararslan ararslan added the julep Julia Enhancement Proposal label Dec 11, 2018
@JeffBezanson
Copy link
Member

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.

@JeffBezanson
Copy link
Member

See also #29875

@jrevels
Copy link
Member Author

jrevels commented Dec 11, 2018

Given that #6383 and #29875 are already issues, should this be closed in favor of those?

@jrevels
Copy link
Member Author

jrevels commented Dec 19, 2018

Closing as a dup of #29875

@jrevels jrevels closed this as completed Dec 19, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
julep Julia Enhancement Proposal
Projects
None yet
Development

No branches or pull requests

4 participants