-
Notifications
You must be signed in to change notification settings - Fork 142
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
Allow non-literal bitstype immutables as type parameters #204
Comments
This was referenced Jan 27, 2015
simonster
added a commit
that referenced
this issue
Apr 24, 2015
On 0.4, we can't differentiate between these and tuples of types that were saved by earlier versions of Julia. In earlier versions of Julia, such tuples were not bits typed so they would not have been usable anyway. We can revisit this when we're ready to change the file format (perhaps as part of #204/#218)
simonster
added a commit
that referenced
this issue
Apr 25, 2015
On 0.4, we can't differentiate between these and tuples of types that were saved by earlier versions of Julia. In earlier versions of Julia, such tuples were not bits typed so they would not have been usable anyway. We can revisit this when we're ready to change the file format (perhaps as part of #204/#218)
simonster
added a commit
that referenced
this issue
Apr 25, 2015
On 0.4, we can't differentiate between these and tuples of types that were saved by earlier versions of Julia. In earlier versions of Julia, such tuples were not bits typed so they would not have been usable anyway. We can revisit this when we're ready to change the file format (perhaps as part of #204/#218)
closing since this seems like a JLD issue. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is the unfinished work from #203: while types can now have arbitrary bitstype immutables as parameters, JLD does not support it.
Currently, the type is simply represented as a string, like
Foo{Bar(1)}
. Unfortunately, to construct the type from such a string, we'd have toeval
the contents as the inverse of 5c7db4d does. SinceBar(1)
is printed without its module name and could do anything, we cannot do this safely (even if Bar is a bits immutable, its constructor could do something nasty).So I think we'll have to look into a new way of serializing type parameters as @simonster suggested in #203 (comment):
The text was updated successfully, but these errors were encountered: