JuliaLang / julia

The Julia Programming Language
https://julialang.org/
MIT License
45.77k stars 5.49k forks source link

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

Open AzamatB opened 4 years ago

AzamatB commented 4 years ago

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:ox: 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.

JeffBezanson commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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.