Inability to dup/~ for const arrays of class objects

Michel Fortin michel.fortin at michelf.ca
Tue May 28 20:09:56 PDT 2013


On 2013-05-29 02:25:01 +0000, "Steven Schveighoffer" 
<schveiguy at yahoo.com> said:

> On Tue, 28 May 2013 22:20:08 -0400, Jonathan M Davis 
> <jmdavisProg at gmx.com>  wrote:
> 
>> The syntax is actually the easy part. The problem is that the type system
>> itself doesn't differentiate between a class and a reference to a class,  and
>> the whole compiler is wired that way. So, while adding a new syntax  isn't that
>> hard (several have been proposed before), actually implementing it is a  royal
>> pain (enough so that Walter gave up on it). It would definitely be nice 
>>  to have
>> that fixed though.
> 
> No, this is wrong.  The issue is entirely syntax.  And it is hard, 
> because  *conceptually*, it's difficult to separate out the reference 
> from the  data.  It's hard to say "The part of C that isn't the 
> reference" in a  succinct way.
> 
> Michel Fortin has created a pull request to make
> 
> const(T)ref
> 
> work, and only apply the const to the data.  It's certainly doable.  
> But  the syntax, as you can see, is ugly.

Well, that pull request wasn't trivial to implement correctly and the 
syntax took some time to come with. And also there's no guaranty Walter 
would have accepted the somewhat contorted solution even though it was 
working pretty well (but with no review comment it's hard to say).

> As it turns out, we need more than this, and a more critical problem to 
>  solve is creating tail-const custom ranges (I am working on an article 
> to  discuss and hopefully address this).

It's a different problem that'll require a different solution, and if 
it requires special syntax it should be at the struct declaration, not 
at the type declaration. Something like that:

	struct MyRange(inheritedconstness(T)) {
		T[] bla;
		this(const MyRange r) { bla = r.bla; }
	}

	immutable(MyRange!T) t; // real type becomes immutable(MyRange!(immutable(T))
	MyRange!(immutable(T)) u = t; // calls above constructor

Wouldn't this be enough?

-- 
Michel Fortin
michel.fortin at michelf.ca
http://michelf.ca/



More information about the Digitalmars-d mailing list