relax disabled Final!T unary operators

[Jonathan M Davis via Digitalmars-d]

On Friday, March 24, 2017 11:00:20 H. S. Teoh via Digitalmars-d wrote:
> 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.)

Well, final in Java (which is what I assume Final is trying to emulate) is
basically head-const. So, if you have a pointer or reference, it would be
const, and the rest would be mutable, whereas for types that are not
essentially pointers end up being fully const. As such, I would have
half-expected Final to just work with pointers and class references, but if
it did work with other types, then either it would make anything directly in
the type read-only, or it would make the whole type const.

Even trying to emulate Java's semantics, it does get a bit funny, because
all aggregate types in Java are reference types. So, something like a struct
containing a pointer just isn't something that Java's final has to worry
about, and if we're trying to emulate it, we're forced to come up with our
own semantics. However, I think that what's most in the spirit of Java's
final would be to make everything directly in the struct read-only - which
in the case of dynamic arrays (which are essentially a struct) would mean
that you could alter the elemens but not ptr or the length (regardless of
whether altering the length would alter ptr).

Now, how implementable that is, I don't know (certainly, it sounds like
there are currently quite a few problems with what we currently thave), but
if we can't do it right, we should probably just restrict Final to classes
and pointers.

I don't really have much of a horse in the race though, because I've always
thought that Java's final was an utter waste of time. It's making exactly
the wrong thing const. If we have it, I'd like to see it implemented in a
manner which is not buggy and full of holes, because quality matters, but I
don't really think that it was worth adding in the first place.

- Jonathan M Davis