Another grey area (or more precisely, problematic area) with Final is
dynamic arrays. To wit:
Final!(int[]) arr;
arr.length += 1; // correctly rejected
arr.length = 10; // accepted - WAT?
arr.ptr++; // correctly rejected
arr.ptr = null; // correctly rejected
Bugzilla: https://issues.dlang.org/show_bug.cgi?id=17272
Why is it that .length can be assigned, but arr.ptr cannot? (Note that
altering .length may alter .ptr as well, even though direct assignment
to .ptr is rejected.)
It's probably an implementation detail of how Final is implemented...
but still, this does raise the question: should Final allow changing
aggregate members? Dynamic arrays being a special kind of aggregate in
that we normally think of their members as the array elements
themselves, but in implementation dynamic arrays are slices, which are
structs consisting of a pointer and a length. If Final is meant to be
head-const, wouldn't the "head" portion be .length and .ptr? So we
ought to reject any attempt to modify them. But on the other hand, if we
allow modifying Final struct members, then this is again inconsistent.
All in all, it seems that Final, as currently implemented, really only
makes sense for class types. It seems to have glaring holes and
inconsistency problems with other types. (Just wait till I try it on a
union... that's gonna throw things off, I'm almost certain.)
T
--
Those who've learned LaTeX swear by it. Those who are learning LaTeX swear at
it. -- Pete Bleackley
