Open AzamatB opened 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.
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)?
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.
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
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.
Pasting below the relevant discussion from Slack's #gripes channel. I really like the suggested feature and would love to have it in Julia.