On Wednesday, 29 May 2013 at 01:33:57 UTC, Steven Schveighoffer wrote:
> On Tue, 28 May 2013 21:19:49 -0400, Ali Çehreli <acehreli@yahoo.com> wrote:
>
>>     // C is a class
>>     const(C) c = new const(C);
>>
>>     // c promises that it won't mutate the object.
>>     // Why can't it promise to not mutate another object?
>>
>>     c = new const(C);  // <-- compilation error
>>
>> I don't see the rationale for disallowing the last line. I think it should work without any syntax change. Merely the class handle is being changed.
>
> The issue is that you cannot separate out the reference from the referred-to data, and apply const only to the tail.
>
> It's a syntax issue, not a semantic issue.  It should be allowed, but we lack the syntax to specify it.  You can only apply const to both the reference and the data.
>
> -Steve

At the moment type qualifiers are also implicitly storage classes, I wonder if it would cause any problems to separate the two uses out...

For a class:
const(C) myvar;   // Normal variable holding a const(C)
const C myvar;    // Const variable holding a const(C) (due to transitivity)

For a struct:
const(S) myvar;   // Const-ness of struct leaks out to variable because it is a value type
const S myvar;    // Const variable holding a const(S) (due to transitivity)

On Tuesday, May 28, 2013 20:37:12 Steven Schveighoffer wrote:
> This is a different problem. Your problem is you can't apply const selectively to the tail of the reference. It's fundamentally sound, but D lacks the syntax to do it.

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.

- Jonathan M Davis

On Tuesday, May 28, 2013 18:19:49 Ali Çehreli wrote:
> I remember the discussions on that topic and various syntax proposals but I don't remember why class variable assignment syntax would not work:

The problem is that the type system does not differentiate between a class object and a reference to a class object. The type refers explicitly to the reference, not the object. It doesn't have the concept of a class object separate from its reference, so regardless of what syntax could be proposed, the compiler needs to be rewired a fair bit with regards to classes in order to make it possible to separate the class object and the reference pointing to it. Walter tried it but gave up on it after having quite a few problems with it. I fully expect that it's feasible, but it's hard enough that it hasn't happened. Someone (Michel Fortin IIRC) created one of the first dmd pull requests with a possible solution, but Walter didn't get around to reviewing it (probably because he was sick of dealing with the issue), and it suffered bitrot to the point that it was dropped. I don't know how viable that pull request was, but someone else would need to put in similar effort (if not more) in order to rewire the compiler enough to understand the difference between a class object and its reference.

- Jonathan M Davis

On Tue, 28 May 2013 22:20:08 -0400, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> On Tuesday, May 28, 2013 20:37:12 Steven Schveighoffer wrote:
>> This is a different problem. Your problem is you can't apply const
>> selectively to the tail of the reference. It's fundamentally sound, but D
>> lacks the syntax to do it.
>
> 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.

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

-Steve

On Tuesday, May 28, 2013 22:25:01 Steven Schveighoffer wrote:
> On Tue, 28 May 2013 22:20:08 -0400, Jonathan M Davis <jmdavisProg@gmx.com>
> 
> wrote:
> > On Tuesday, May 28, 2013 20:37:12 Steven Schveighoffer wrote:
> >> This is a different problem. Your problem is you can't apply const
> >> selectively to the tail of the reference. It's fundamentally sound, but
> >> D
> >> lacks the syntax to do it.
> > 
> > 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.

Every time that this comes up and Walter comments on it, he makes a point of saying that it's _not_ a syntax issue.

- Jonathan M Davis

On Tue, 28 May 2013 22:57:50 -0400, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> Every time that this comes up and Walter comments on it, he makes a point of
> saying that it's _not_ a syntax issue.

I remember differently, but maybe you are right.  Haven't the time to look back.

But even if he *does* say that, I think it's more that we haven't found the *right* syntax.

It's certainly only a syntax issue from a specification perspective, there is nothing inherently difficult about the underlying details.

-Steve

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

> On Tue, 28 May 2013 22:20:08 -0400, Jonathan M Davis <jmdavisProg@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@michelf.ca
http://michelf.ca/

On Tuesday, May 28, 2013 23:03:10 Steven Schveighoffer wrote:
> On Tue, 28 May 2013 22:57:50 -0400, Jonathan M Davis <jmdavisProg@gmx.com>
> 
> wrote:
> > Every time that this comes up and Walter comments on it, he makes a
> > point of
> > saying that it's _not_ a syntax issue.
> 
> I remember differently, but maybe you are right. Haven't the time to look back.
> 
> But even if he *does* say that, I think it's more that we haven't found the *right* syntax.
>
> It's certainly only a syntax issue from a specification perspective, there is nothing inherently difficult about the underlying details.

It's primarily an implementation issue. As far as the spec itself goes, it shouldn't be a problem. As far as the spec goes, it's pretty much just a question of picking a good syntax. But getting that to work with the compiler when it doesn't differentiate between the class object and the reference to it in the type system isn't necessarily easy. As I recall, that was the core of what caused Walter so many problems when he worked on it in the past.

- Jonathan M Davis

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

> On 2013-05-29 02:25:01 +0000, "Steven Schveighoffer" <schveiguy@yahoo.com> said:
>
>> On Tue, 28 May 2013 22:20:08 -0400, Jonathan M Davis <jmdavisProg@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

On 2013-05-29 03:09:56 +0000, Michel Fortin <michel.fortin@michelf.ca> said:

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

Ah, well no it won't work if you want to copy or reinterpret it as a MyRange!(const(T)) or const(MyRange!T).

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