On Mon, 29 Nov 2010 11:19:29 -0500, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
On 11/29/10 10:12 AM, Steven Schveighoffer wrote:
On Mon, 29 Nov 2010 10:54:04 -0500, Nick Sabalausky <a...@a.a> wrote:
"Steven Schveighoffer" <schvei...@yahoo.com> wrote in message
news:op.vmxqi4kmeav...@steve-laptop...
On Sun, 28 Nov 2010 23:19:44 -0500, Jack <j...@overlook.biz> wrote:
The post "C#'s greatest mistakes" prompts/begs this post. Have at it,
pick up the ball and run with it, don't be shy. I expect Walter and
Andrei to answer (if Walter and Andrei so dare!) after others' posts
have
stopped or stagnated into that cesspool of threaded discussion that
is
"the subthread" or "tangential thread" (which surely needs a rock
anthem).
As I understand this is a troll post, but still provoked some good
discussion, I'll throw in my biggest problem with D:
lack of tail-const/immutable for classes.
I've heard this before, but I'm a little unclear. Can you give an
example?
This is a tail-const pointer:
const(int)* ptr;
I can reassign ptr at will:
ptr = &x;
ptr = &y;
but I can't change what ptr points to:
*ptr = 5; // error
Because classes are references, just like pointers, I would like a way
to have a tail-const class reference. But it's not possible:
const(C) myref;
myref = a; // error, cannot change const myref
You can have a tail-const pointer to a class reference:
C myref;
const(C) *myrefptr = &myref;
But a class is on the heap, and the reference 'myref' is on the stack,
so myrefptr is only usable locally. In order to keep the 'infinite'
lifetime property, I have to create a class reference on the heap, and
then return a pointer to *that*. Just try to create a class reference on
the heap.
Not only that, but I now have to waste 16 bytes of heap space just to
have a tail-const class reference, *just because* the syntax is
incomplete. I find this unacceptable.
-Steve
Syntax is the main issue in implementing this feature. Due to the
implicit nature of reference semantics for classes, there was no syntax
to distinguish between the head and the tail when qualifying.
Syntax is the main issue, but another issue is Walter's patience -- he
already has stated that he has no interest in entertaining new solutions
because he's already wasted enough time on it.
FWIW I just thought of this syntax. It might work but it's not intuitive:
const()C tailConst;
I think this fails for the same reason const(C) meaning tail const and
const C meaning full const failed -- with parentheses, const applies to
whatever is in them, and the C reference is outside the parentheses.
I can't see any other way than creating a new 'keyword' to denote
tail-const. Whether this be library defined or compiler defined remains
to be seen.
My favorite in recent times is:
@tail const(C) tailconst;
Ultimately I believe we need to make Rebindable palatable. That would
have the nice side effect of enabling other proxy types.
I think if we get to that point, D will be much more adept at doing a lot
of const things (such as ranges of const types).
The big hurdle is implicit casting IMO. For example C and
Rebindable!(immutable C) needs to implicitly cast to Rebindable!(const
C). Right now, builtins and arrays are the only type constructions that
enjoy implicit casting to their tail-const counterparts. Until we solve
this, any library solution is going to be woefully inadequate.
-Steve
