Translate between Core.Nothing and Core.Void #218
Comments
|
Yes, I've been also thinking we need a general translation infrastructure. Might also help with #209. |
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
simonster
added a commit
that referenced
this issue
Apr 25, 2015
Converts between Tuple{} and () types depending on Julia version. Also
fixes #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)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
@timholy added code to perform special serialization of Nothing/Void, but we're still reconstructing these types when reading JLD files created with older versions of JLD instead of mapping them to their new names (e.g. JuliaLang/julia#10289). We could do this with a regexp hack like what we have for UInt, but it would be better to have a general solution that doesn't have the potential to cause problems with user-defined types. The same probably holds for String/AbstractStrings. Related to #204.
The text was updated successfully, but these errors were encountered: