Should the "front" range primitive be "const" ?
Simen Kjærås
simen.kjaras at gmail.com
Mon Feb 5 02:12:26 UTC 2018
On Friday, 2 February 2018 at 14:29:34 UTC, H. S. Teoh wrote:
> Its semantics are not broken; it's just harder to use. Due to
> const transitivity, it's an all-or-nothing deal. .tailConst
> gives us the middle ground.
If the semantics of const means that users will have to write
.tailConst all over the place, it's broken. If it means that
users can't use const(T) because they actually want TailConst!T,
it's broken.
TailConst seems like the logical solution to the problem, but it
isn't. It directly impacts user code and it leads to lots of
boilerplate. In addition to .tailConst, we also need
.tailImmutable. And to top it off, it just doesn't mix with const
at all - if you pass it as a const parameter, it's broken. If
it's part of a struct or class with const methods, it's broken.
It infects every part of your codebase that touches it, it forces
you to basically implement your own const system in templates,
and it makes const even harder to use than it currently is.
Tail-const is the more intuitive way to think of it, so if I'm
wrong, please show me.
>> Once we've defined immutable(RefCounted!T) to be undefined
>> behavior,
>> suddenly casting from const(RefCounted!T) to
>> RefCounted!(const(T)) is
>> OK again.
> [...]
>
> The problem with this is that we're now relying on convention
> rather than something that can be statically verified by the
> compiler. Once you allow casting away const, there's no longer
> a guarantee that somebody didn't pass in an immutable, whether
> by mistake or otherwise. We know from C/C++ where programming
> by convention leads us. :-P
True. Sadly, there's no way to tell the type system 'this type
should never be immutable'. Maybe such a thing should be in the
language. Meanwhile, if RefCounted!T implements .headMutable, it
can check at runtime that the refcount is in writable memory.
> Though the above currently doesn't compile, it seems because
> the compiler doesn't know how to resolve Wrapper!(const(T))
> given a Wrapper!T despite the alias this.
Yeah, I found the same bug when playing with .headMutable:
https://issues.dlang.org/show_bug.cgi?id=18260
--
Simen
More information about the Digitalmars-d-learn
mailing list