Problem: end is a keyword

[c-rack]

end is a (reserved?) keyword in Elixir, which we should avoid as a struct field name, see:
https://github.com/elixir-lang/elixir/blob/7b5f4a5842d05bf279b249078fd9051e3dcafa50/lib/elixir/src/elixir_tokenizer.erl#L1037

While this does not cause problems in actual code yet (except broken syntax highlighting), I would strongly advise to change the CIDR struct members start / end to first / last.

This will break backward compatibility, but I think it is better to change it now than later.

@duijf what do you think?

[duijf]

I'm torn on this.

I'm tempted to say that the code compiles: why change unless we have to?

On the other hand I can see the annoyance in breaking syntax highlighting, and who knows if our code will always be valid? Breaking backwards compatibility now is better than later, especially when we could have seen this comming.

Since we have a fair number of downloads (6k), we do need to issue a deprecation warning first. I'm not sure how to do that with struct keys, though.

[c-rack]

I would assume that most users do not directly use the start and end fields of the struct, but rather the match functions in most cases. Nevertheless, let's search for a migration path.

My idea is to add functions that work as accessors to the struct and to treat the struct itself as an opaque object that no project should work directly with. So we would introduce a first/1 and last/1 function and add a warning to README and changelog that direct usage of struct fields is deprecated.

# For example:
x     = "127.0.0.1/24" |> CIDR.parse
first = x |> CIDR.first
last  = x |> CIDR.last

Does it make sense?

[c-rack]

Another idea is to add first and last as fields to the struct and duplicate start and end values. That way, new code could use the new struct fields while old code does not need to be updated, yet. We add a deprecation warning to README and changelog finally remove start / end fields on 1.0 release.