Inability to dup/~ for const arrays of class objects

[Steven Schveighoffer]

On Tue, 28 May 2013 23:09:56 -0400, Michel Fortin  
<michel.fortin at michelf.ca> wrote:

> 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).

I was not trying to say it was trivial, I'm sorry if it came across that  
way.  What I really meant was that if it was difficulty of implementation,  
Walter would have pulled that request seeing as you did all the work!

I don't think it's as much an issue with implementation as it is concept  
and perception.  To say that "C ref" is the same as C is really difficult  
to swallow, then you have ref const(C) ref, which looks horrible IMO.

>> 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?

I thought some sort of template (or parameterized) solution also.  I'm  
pretty convinced now that this method is unworkable.

I have an article I haven't touched since the plane ride home from dconf  
which discusses these problems, I need to finish it.  I think I have a  
good solution for both this and object references.  I don't want to set  
any expectations, so I'll leave it at that :)

-Steve