PSA: New keywords for defining types

Internals & Design
21

How do I adapt my code to this change so that it works with Julia v0.5 and Julia v0.6? Does Compat have support for this change?

I tried the following in a branch, but it fails to compile.

@compat struct WAVFormat
    compression_code::UInt16
    nchannels::UInt16
    sample_rate::UInt32
    bytes_per_second::UInt32 # average bytes per second
    block_align::UInt16
    nbits::UInt16
    ext::WAVFormatExtension
end

Thanks

1 Like
22

type and immutable still work in Julia 0.6 without deprecated warnings. So I think the best way to write compatible code with Julia 0.5 and 0.6 is to keep using type and immutable for a while and change them to mutable struct and struct when you drop Julia 0.5 support in the future.

23

I’m loving all the changes except I’m still a bit hung-up on const or not-const in the new typealiases:

Vector{T} = Array{T,1}
const BitVector = BitArray{1}

For whatever reason, the disagreement here grates me…

2 Likes
24

You should be able to add the const in the former case just for visual consistency, even though it’s implied.

25

Thanks Tony. Yes, I do understand that :slight_smile:

I’m just a little unsure the long-term plan is here? This type of inconsistency seems fine while we wait for something else to deprecate or change behavior. Do we plan to allow the latter statement without the const? (This would seem to change the nature of toplevel bindings). And if not, what is the advantage of allowing the former? Or are we happy with this the way it is? Maybe it’s just me! :slight_smile:

26

It’s not just you, it bugs me a little too. I think some people might like to see the need for const go away completely, but I’m not sure on what horizon that might be feasible. Having const be the default could be a pretty major change.

2 Likes
27

Right, it seems just a little weird in the current situation where we have one particular form of one particular type of statement have implied const and everything else is non-const by default.

(I would have expected const in both cases, with the advantage of getting more of the community to understand the simplicity of UnionAll. If we want to make toplevel statements const by default this seems rather orthogonal).

28

(though I’m actually supportive of making const by default, at least inside most modules. What would be epic/awesome is compiler dependency edges for consts that might change, e.g. at the REPL)

29

I think it is reasonable to special case the REPL here. I would guess that for most REPL work, having many methods be recompiled when consts change could be annoying.