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
This issue stems from a question I asked on Julia Slack and @jakobnissen, who was helping me (thanks again!), thought it was worth submitting an issue about it.
I have an existing parametric type of the form E{S,C} and an abstract parametric type of the form I{S,C}.
I was trying to define a new parametric subtype CS of I. I initially implemented it like
struct CS{ES,EC,S} <:I{S,EC}
where ES and EC are parameters of the existing E.
Then, I felt it would be logically more clear if instead of sticking ES and EC from E directly as parameters of CS, if I just made E{ES,EC} a parameter of CS. Something like
struct CS{E{ES,EC},S} where {ES,EC,S} <:I{S,EC}
Unfortunately, it seems this syntax is unavailable.
I think thatt's impossible. A shame, it would make type signatures for things like static arrays and subarrays much more concise.
He couldn't find an issue related to this and, after asking if it made sense, he said it would make sense to submit an issue so here you go :)
I don't know the ramifications to static arrays or subarrays, but it would make my code a little cleaner I think if this syntax were available. Are there any existing issues related to this that we've missed?
Edit: The more I look at it, the more I think
struct CS{E{ES,EC},S} where {ES,EC,S} <:I{S,EC}
should be valid syntax so I'm almost certain this has been discussed. To my eye, it seems perfectly consistent with what we do with methods.
Edit^2: Or maybe
struct CS{E{ES,EC},S} <:I{S,EC}
could just work without the where 🤔
The text was updated successfully, but these errors were encountered:
EricForgy
changed the title
Passing a parameter from parametric parameter to an abstract parametric type
Passing a parameter from a parametric parameter to an abstract parametric type
Jun 21, 2020
This would probably be difficult to implement, since it breaks fundamental assumptions about the structure of types. For field types, it can be implemented on top of #18466 (by calling a function to pull the parameter out of E when the first parameter to CS becomes known), but the supertype is trickier.
Hi,
This issue stems from a question I asked on Julia Slack and @jakobnissen, who was helping me (thanks again!), thought it was worth submitting an issue about it.
I have an existing parametric type of the form
E{S,C}
and an abstract parametric type of the formI{S,C}
.I was trying to define a new parametric subtype
CS
ofI
. I initially implemented it likewhere
ES
andEC
are parameters of the existingE
.Then, I felt it would be logically more clear if instead of sticking
ES
andEC
fromE
directly as parameters ofCS
, if I just madeE{ES,EC}
a parameter ofCS
. Something likeUnfortunately, it seems this syntax is unavailable.
@jakobnissen commented:
He couldn't find an issue related to this and, after asking if it made sense, he said it would make sense to submit an issue so here you go :)
I don't know the ramifications to static arrays or subarrays, but it would make my code a little cleaner I think if this syntax were available. Are there any existing issues related to this that we've missed?
Edit: The more I look at it, the more I think
should be valid syntax so I'm almost certain this has been discussed. To my eye, it seems perfectly consistent with what we do with methods.
Edit^2: Or maybe
could just work without the
where
🤔The text was updated successfully, but these errors were encountered: