On Tue, 28 May 2013 23:09:56 -0400, Michel Fortin
<michel.for...@michelf.ca> wrote:
On 2013-05-29 02:25:01 +0000, "Steven Schveighoffer"
<schvei...@yahoo.com> said:
On Tue, 28 May 2013 22:20:08 -0400, Jonathan M Davis
<jmdavisp...@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
