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

Feature request: support for "private" type parameters #36201

Open
AzamatB opened this issue Jun 8, 2020 · 5 comments
Open

Feature request: support for "private" type parameters #36201

AzamatB opened this issue Jun 8, 2020 · 5 comments
Labels
kind:feature Indicates new feature / enhancement requests kind:speculative Whether the change will be implemented is speculative

Comments

@AzamatB
Copy link
Contributor

AzamatB commented Jun 8, 2020

Pasting below the relevant discussion from Slack's #gripes channel. I really like the suggested feature and would love to have it in Julia.

Lyndon White🐂
Maybe could have something like

struct Foo{T}
    a::T
    b::Int
    c::<:Any
end

where the type of c is like an implicit type-parameter that doesn’t get shown and can’t be dispatched on. ::<:Any would mirror Vector{<:Any} anon type-param constraints. Though there might be a different syntax that is nicer. Such a thing would also clean up SubArray a lot if we could do it.

Andy Ferris
This relates somewhat to covariant structs. The previous example Foo{T} where T is like Tuple{T, Int, Any} where T in terms of layout, dispatch, and specialization.

@KristofferC KristofferC added kind:feature Indicates new feature / enhancement requests kind:speculative Whether the change will be implemented is speculative labels Jun 8, 2020
@JeffBezanson
Copy link
Sponsor Member

where the type of c is like an implicit type-parameter that doesn’t get shown

I get the motivation here, but this is going to have its share of problems. If we don't show all of the parameters, then you don't have enough information to do anything with the type. For example, if you pass the printed type to code_typed it will not know the type of the c field, so you won't see the correct code.

Such a thing would also clean up SubArray a lot if we could do it.

An example would be helpful here --- i.e. some SubArray code or method definitions, and what you would like to be able to rewrite them to. I'm not sure how disallowing dispatch on some parameters helps, and there are SubArray methods that use all of its parameters, so I'm not sure what would happen to those.

@vtjnash
Copy link
Sponsor Member

vtjnash commented Jun 8, 2020

Sounds like a duplicate of #18466, and the feature is already implemented in https://github.com/vtjnash/ComputedFieldTypes.jl (which addresses exactly those problems Jeff mentioned)?

@JeffBezanson
Copy link
Sponsor Member

Ah yes, in many cases extra type parameters could be dropped if they could be computed from other parameters. But IIUC this is also asking for field types that depend on the types of field values, not just other parameters.

@AzamatB
Copy link
Contributor Author

AzamatB commented Jun 9, 2020

An example would be helpful here --- i.e. some SubArray code or method definitions, and what you would like to be able to rewrite them to

Pinging @andyferris and @oxinabox to this conversation. Maybe they can provide the motivating examples

@oxinabox
Copy link
Contributor

oxinabox commented Jun 9, 2020

I am not nesc sure this is a good idea, there is a reason it was on slack and not in an issue.
My recollection of the motivation (which this was posted as a "Maybe we could",
was someone talking about the problems with structs with abstractly typed fields.
and how it was "always better to make those types into type-parameters".
which itself is a premise i disagree with, since sometimes things are just not worth specializing on.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind:feature Indicates new feature / enhancement requests kind:speculative Whether the change will be implemented is speculative
Projects
None yet
Development

No branches or pull requests

5 participants