www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Why can't we define re-assignable const reference variable?

reply none <z gg.com> writes:
Why can't we define re-assignable const reference variable?
i.e. the variable can be re-bind, but it's allowed to change the object it
points to:

This is such a pain to port D 1.0 code to 2.0, e.g. I have some code in D 1.0
like this:

========================
  B b1, b2;
  b1 = new B();
  b2 = new B();

  B b;
  b = b1;
  b.MemberFunc();         // later change to const member function
  b = b2;
  b.anotherMemberFunc();  // later change to const member function
========================

When porting to D 2.0, some of the method of class B is changed to const
member function, and I want to make my intention clear, so I changed 'B b', to
be 'const B b'.

Now the trouble is, b can only be init-ed once, but cannot be re-assigned.

I know I can use pointer to achieve what I want:

========================
  B b1, b2;
  b1 = new B();
  b2 = new B();

  const(B)* b;            // type change
  b = &b1;                // additional change
  b.constMemberFunc();
  b = &b2;                // additional change
  b.anotherConstMemberFunc();
========================

Then I have to change the code in multiple places; and the other problem is
that I will have to use pointers most of the time in my code.

So why can't we have both (just as in C++):

========================
const B b;  // b cannot be re-bind, and the object cannot be modified
B const b;  // b can    be re-bind, but the object cannot be modified
========================
Feb 16 2008
next sibling parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 16/02/2008, none <z gg.com> wrote:

  So why can't we have both (just as in C++):


This has been covered so many times before, but in summary, allowing
that would completely break the type system.

But I just want to clear up one misconception. You /cannot/ do that in
C++. References in C++ are /never/ rebindable.
Feb 16 2008
next sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
Janice Caron wrote:

 On 16/02/2008, none <z gg.com> wrote:

  So why can't we have both (just as in C++):


 
 This has been covered so many times before, but in summary, allowing
 that would completely break the type system.


What's the difference (save polymorphism) between a pointer to a struct 
and a reference to an object?
Feb 16 2008
parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 16/02/2008, Christopher Wright <dhasenan gmail.com> wrote:

 What's the difference (save polymorphism) between a pointer to a struct
  and a reference to an object?


I don't understand the question.

What's the difference between chalk and cheese? What are you getting at?
Feb 16 2008
parent reply Christopher Wright <dhasenan gmail.com> writes:
Janice Caron wrote:

 On 16/02/2008, Christopher Wright <dhasenan gmail.com> wrote:

 What's the difference (save polymorphism) between a pointer to a struct
  and a reference to an object?


 
 I don't understand the question.
 
 What's the difference between chalk and cheese? What are you getting at?


Well, chalk has a significantly higher calcium content and has usually 
not gone through a cow.

In C++, there's no difference between the two. In D, the difference 
appears to be that there is no syntax separate the reference from the 
object, besides an ugly cast.

I've never heard any explanation of how reassignable const objects would 
break the type system, and it seems to me that, if they would, then you 
shouldn't be able to do:
struct Foo{}
const(Foo)* fptr;
Feb 16 2008
parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 16/02/2008, Christopher Wright <dhasenan gmail.com> wrote:

 What's the difference (save polymorphism) between a pointer to a struct
  and a reference to an object?




 In C++, there's no difference between the two.


Yes there is.

    S * p = whatever;
    S & r = whatever;

p can be rebound. r can't.


 In D, the difference
 appears to be that there is no syntax separate the reference from the
 object, besides an ugly cast.


And nor is there in C++. You cannot modify r. There is no way to get
at r. You can't even take the address of r. C++ prohibits you, and no
one's ever complained that that's a problem. If you want to rebind,
you use a pointer.



 I've never heard any explanation of how reassignable const objects would
 break the type system,


Because you'd need a brand new syntax to do it, and whatever syntax
you chose, it would break generic programming.



 and it seems to me that, if they would, then you
 shouldn't be able to do:
 struct Foo{}
 const(Foo)* fptr;


There's no problem with that. fptr is a pointer, not a reference.
Feb 16 2008
parent reply Christopher Wright <dhasenan gmail.com> writes:
Janice Caron wrote:

 On 16/02/2008, Christopher Wright <dhasenan gmail.com> wrote:

 What's the difference (save polymorphism) between a pointer to a struct
  and a reference to an object?




 In C++, there's no difference between the two.


 
 Yes there is.
 
     S * p = whatever;
     S & r = whatever;
 
 p can be rebound. r can't.


Hm. Perhaps I should learn c++ before talking about it.


 I've never heard any explanation of how reassignable const objects would
 break the type system,


 
 Because you'd need a brand new syntax to do it, and whatever syntax
 you chose, it would break generic programming.


generic programming != type system

I forgot about that argument, though. Thanks for reminding me. The 
solution, of course, is first-class references for everything, which 
Walter isn't willing to do. In almost every circumstance, it'd be 
duplicated functionality.
Feb 16 2008
parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 16/02/2008, Christopher Wright <dhasenan gmail.com> wrote:

 generic programming != type system


I can't argue with that! :-) Perhaps I should have said, it will break
/either/ generic programming /or/ the type system. I suppose I was
thinking that if you have new syntax, and you want to keep generic
programming, then somehow you must force the new syntax to work for
all types, and /that/ breaks the type system, but I guess I was
probably thinking too far ahead there. :-)
Feb 16 2008
parent reply Robert Fraser <fraserofthenight gmail.coim> writes:
Janice Caron Wrote:


 On 16/02/2008, Christopher Wright <dhasenan gmail.com> wrote:

 generic programming != type system


 
 I can't argue with that! :-) Perhaps I should have said, it will break
 /either/ generic programming /or/ the type system. I suppose I was
 thinking that if you have new syntax, and you want to keep generic
 programming, then somehow you must force the new syntax to work for
 all types, and /that/ breaks the type system, but I guess I was
 probably thinking too far ahead there. :-)


D already has types that break generic programming. Static arrays, anyone?

One thing I was arguing for before the const system was implemented as it is
now is for structs to act as similarly to classes as possible, only stack
allocated. So while there was still a question of "head-const" and
"tail-const", a "tail-const" struct would be the same as a "tail-const" class:
that is, the reference would be rebindable, but members would not be. For
example:

struct S { int x; }
class C  { int x; }

tailconst(S) s1;
tailconst(S) s2;

tailconst(C) c1 = new C();
tailconst(C) c2 = new C();

s1 = s2; // Okay
c1 = c2; // Okay
s1.x = 5; // Not okay
c1.x = 5; // Not okay

When I proposed this, NOBODY agreed with me (that is, everybody who responded
wanted structs/classes to act differently for generic programming purposes).
Feb 17 2008
next sibling parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 17/02/2008, Robert Fraser <fraserofthenight gmail.coim> wrote:

 s1 = s2; // Okay
 c1 = c2; // Okay
 s1.x = 5; // Not okay
 c1.x = 5; // Not okay

 When I proposed this, NOBODY agreed with me (that is, everybody who responded
wanted structs/classes to act differently for generic programming purposes).


Isn't that rather because modifying s1.x modifies s1?
Feb 17 2008
parent Robert Fraser <fraserofthenight gmail.coim> writes:
Janice Caron Wrote:


 On 17/02/2008, Robert Fraser <fraserofthenight gmail.coim> wrote:

 s1 = s2; // Okay
 c1 = c2; // Okay
 s1.x = 5; // Not okay
 c1.x = 5; // Not okay

 When I proposed this, NOBODY agreed with me (that is, everybody who responded
wanted structs/classes to act differently for generic programming purposes).


 
 Isn't that rather because modifying s1.x modifies s1?


Technically, yes. But what I was (and still am) campaigning for is syntax
changes where by "struct S" can be changed to "class X" and no client code will
be broken at all. Structs/classes should behave differently from an
implementation perspective (not like C++), so for example structs are data
types/stack allocated and don't support inheritance, but they should be usable
in roughly the same way by clients. This removes the decision from the API for
most purposes.
Feb 17 2008
prev sibling parent Christopher Wright <dhasenan gmail.com> writes:
Robert Fraser wrote:

 Janice Caron Wrote:
 

 On 16/02/2008, Christopher Wright <dhasenan gmail.com> wrote:

 generic programming != type system


 I can't argue with that! :-) Perhaps I should have said, it will break
 /either/ generic programming /or/ the type system. I suppose I was
 thinking that if you have new syntax, and you want to keep generic
 programming, then somehow you must force the new syntax to work for
 all types, and /that/ breaks the type system, but I guess I was
 probably thinking too far ahead there. :-)


 
 D already has types that break generic programming. Static arrays, anyone?


Oh dear GOD yes. I'm doing an assertions library right now (cooked it up 
over the past couple days because I got tired of writing assert 
(something, "salient description here")) and strings are absolutely 
KILLING me.

I want to support Tango collections for list constraints, but I can't 
instantiate it with a static array. I can write some ugly templates to 
make it go away, but it's just really annoying.

And then I think sameAs constraints won't work right.

If strings were dynamic arrays, all my troubles would disappear.
Feb 17 2008
prev sibling parent reply none <z gg.com> writes:
== Quote from Janice Caron (caron800 googlemail.com)'s article

 On 16/02/2008, none <z gg.com> wrote:

  So why can't we have both (just as in C++):


 This has been covered so many times before, but in summary, allowing
 that would completely break the type system.


I don't understand why it will break the type system; in any case, even without
it
(as we do now), I can always get around it by using D pointers:

  const(B)* b;            // type change
  b = &b1;                // rebind
  b = &b2;                // rebind

It's just so inconvenient, that's why I suggest allow define re-assignable const
reference variable.


 But I just want to clear up one misconception. You /cannot/ do that in
 C++. References in C++ are /never/ rebindable.


That's a terminology issue, to make it clear:

class C {}

D                           C++
=========================   ===========================
reference: C c = new C();   pointer:    C *c = new C();
pointer:   C* cp = &c;      ptr-to-ptr: C **cp = &c;


What I mean is in C++, you can define 2 different kinds of C++ pointers:

const C* b;  // b cannot be re-bind, and the object cannot be modified
C* const b;  // b can    be re-bind, but the object cannot be modified

So in D we should be able to define 2 different kinds of D reference:

const C b;  // b cannot be re-bind, and the object cannot be modified
C const b;  // b can    be re-bind, but the object cannot be modified
Feb 16 2008
next sibling parent none <z gg.com> writes:
Sorry in C++, it should be


 What I mean is in C++, you can define 2 different kinds of C++ pointers:
 const C* b;  // b cannot be re-bind, and the object cannot be modified


C* const b;


 C* const b;  // b can    be re-bind, but the object cannot be modified


const C* b;

and:
const  C* const b;  // both pointer, and data are const.
Feb 16 2008
prev sibling next sibling parent Christopher Wright <dhasenan gmail.com> writes:
none wrote:

 == Quote from Janice Caron (caron800 googlemail.com)'s article

 On 16/02/2008, none <z gg.com> wrote:

  So why can't we have both (just as in C++):


 This has been covered so many times before, but in summary, allowing
 that would completely break the type system.


 
 I don't understand why it will break the type system; in any case, even
without it
 (as we do now), I can always get around it by using D pointers:


 From Walter's perspective, there are a few choices:
- First-class references. A large language feature to solve a small problem.
- Do nothing.
- Have Andrei cook up a library solution.

For that last, you can't simply put a struct around it and go on your 
merry way. The closest you can reasonably come is:

struct Tailconst(T) {
    T t;
    void opAssign(T value) { t = value; }
    // insert method and operator forwarding here
}
Feb 16 2008
prev sibling next sibling parent reply none <z gg.com> writes:
Actually we can rebind already: this is legal code accepted by the DMD compiler

for (i = n; i-- > 0; ) {
  const B b = getConstB(i);  // are we rebind here n-times already?
  b.doSomething();
}

// the trouble is I cannot use the last 'b' i.e. getConstB(0),
// anymore, it will be out of scope
b.doSomethingElse();



 (as we do now), I can always get around it by using D pointers:
   const(B)* b;            // type change
   b = &b1;                // rebind
   b = &b2;                // rebind
 It's just so inconvenient, that's why I suggest allow define re-assignable
const
 reference variable.
Feb 16 2008
parent Christopher Wright <dhasenan gmail.com> writes:
none wrote:

 Actually we can rebind already: this is legal code accepted by the DMD compiler
 
 for (i = n; i-- > 0; ) {
   const B b = getConstB(i);  // are we rebind here n-times already?
   b.doSomething();
 }


That doesn't really work. For purposes of const, it's as if you wrote:
void loopBody (int i) {
    const B b = getConstB(i);
    b.doSomething();
}

for (i = n; i > 0; i--) {
    loopBody(i);
}


 // the trouble is I cannot use the last 'b' i.e. getConstB(0),
 // anymore, it will be out of scope
 b.doSomethingElse();
 
 

 (as we do now), I can always get around it by using D pointers:
   const(B)* b;            // type change
   b = &b1;                // rebind
   b = &b2;                // rebind
 It's just so inconvenient, that's why I suggest allow define re-assignable
const
 reference variable.


 


Then there's no way to say you don't want to be able to rebind it.
Feb 17 2008
prev sibling next sibling parent reply Sergey Gromov <snake.scaly gmail.com> writes:
none <z gg.com> wrote:

 == Quote from Janice Caron (caron800 googlemail.com)'s article

 On 16/02/2008, none <z gg.com> wrote:

  So why can't we have both (just as in C++):


 This has been covered so many times before, but in summary, allowing
 that would completely break the type system.


 
 I don't understand why it will break the type system; in any case, even
without it
 (as we do now), I can always get around it by using D pointers:
 
   const(B)* b;            // type change
   b = &b1;                // rebind
   b = &b2;                // rebind
 
 It's just so inconvenient, that's why I suggest allow define re-assignable
const
 reference variable.
 

 But I just want to clear up one misconception. You /cannot/ do that in
 C++. References in C++ are /never/ rebindable.


 
 That's a terminology issue, to make it clear:
 
 class C {}
 
 D                           C++
 =========================   ===========================
 reference: C c = new C();   pointer:    C *c = new C();
 pointer:   C* cp = &c;      ptr-to-ptr: C **cp = &c;


This is not how the things currently are.  Actually it's like this:

class C {}
struct S {}

D                           C++
=========================   ===========================
reference: C c = new C();   pointer:    C *c = new C();
pointer:   C* cp = &c;      pointer:    C *cp = c;
value:     S s = {};        value:      S s = {};
pointer:   S* sp = &s;      pointer:    S *sp = &s;
no equiv.                   reference:  C &cr = *c;
no equiv.                   reference:  C &sr = s;

So it's really strange that you can't declare
const(C) x;
All the syntax is here already.

-- 
SnakE
Feb 16 2008
parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 17/02/2008, Sergey Gromov <snake.scaly gmail.com> wrote:

 So it's really strange that you can't declare
 const(C) x;


???

You can!
Feb 16 2008
parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Janice Caron <caron800 googlemail.com> wrote:

 On 17/02/2008, Sergey Gromov <snake.scaly gmail.com> wrote:

 So it's really strange that you can't declare
 const(C) x;


 
 ???
 
 You can!


But it wouldn't mean mutable reference to const data.  This /looks/ like 
const only affecting C, but, in fact, constness is expanded over the 
whole declaration.  I.e. the syntax for declaring reference to const is 
already in the language, the question is, why it's not in the type 
system.

-- 
SnakE
Feb 17 2008
parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 17/02/2008, Sergey Gromov <snake.scaly gmail.com> wrote:

 Janice Caron <caron800 googlemail.com> wrote:

 On 17/02/2008, Sergey Gromov <snake.scaly gmail.com> wrote:

 So it's really strange that you can't declare
 const(C) x;


 ???

 You can!


 But it wouldn't mean mutable reference to const data.


Of course not. That would be impossible.

You cannot have a mutable reference to const data in C++, so what's
the big deal? The best you can achieve in C++ is a mutable /pointer/
to const data, and that is also allowed in D.



 This /looks/ like
 const only affecting C


const is transitive, so it affects C, and everything referenced by C.
It declares the four-byte reference on the stack that is C, to be
const, and since const is transitive, that makes the instance of C's
data on the heap const, and everything referenced therefrom.



 but, in fact, constness is expanded over the
 whole declaration.


Of course. Everything in the brackets is const. That's what's brackets
are for - precedence. C is in the brackets; C is const.



 I.e. the syntax for declaring reference to const is
 already in the language,


You're going to have to clarify that, I'm afraid, as I don't
understand. Are you referring to the function parameter syntax

    ref const(C) c

? In this case, c is indeed rebindable, but only because an extra
level of indirection has been silently added.



 the question is, why it's not in the type
 system.


I don't agree that that's even a reasonable question, because there is
/not/ a syntax for "mutable reference to constant data" (not counting
function parameters).
Feb 17 2008
next sibling parent Sean Reque <seanthenewt yahoo.com> writes:
 
 Of course not. That would be impossible.
 
 You cannot have a mutable reference to const data in C++, so what's
 the big deal? The best you can achieve in C++ is a mutable /pointer/
 to const data, and that is also allowed in D.
 


This argument is completely pointless, because in C++ you don't have references
at all, at least not in the same sense as references are in most every other

Scheme, Javascript, etc. In most languages, including D, references are
basically there to replace pointers as a much safer and more syntactically
pleasing alternative when the full power of pointers isn't needed or desired
(segmentation fault, anyone?). Therefore, references in D should have the same
flexibility as a pointer would. But right now references behave like pointers
in terms of assignment, but const references do NOT behave like const pointers
in terms of assignment, and that simply should not be.
Feb 17 2008
prev sibling parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Janice Caron <caron800 googlemail.com> wrote:

 On 17/02/2008, Sergey Gromov <snake.scaly gmail.com> wrote:

 Janice Caron <caron800 googlemail.com> wrote:

 On 17/02/2008, Sergey Gromov <snake.scaly gmail.com> wrote:

 So it's really strange that you can't declare
 const(C) x;


 You can!


 But it wouldn't mean mutable reference to const data.


 
 Of course not. That would be impossible.
 
 You cannot have a mutable reference to const data in C++, so what's
 the big deal? The best you can achieve in C++ is a mutable /pointer/
 to const data, and that is also allowed in D.


You can't have a mutable reference to mutable data in C++, either.  D 
allows that.  Why allow one but deny the other, I don't get it.


 This /looks/ like
 const only affecting C


 
 const is transitive, so it affects C, and everything referenced by C.
 It declares the four-byte reference on the stack that is C, to be
 const, and since const is transitive, that makes the instance of C's
 data on the heap const, and everything referenced therefrom.


Yes, the C and everything below is const. But why x ?  It doesnt belong 
to C, it's in my function scope.  It's not transitiviness that bothers 
me, but backward transitiviness.


 but, in fact, constness is expanded over the
 whole declaration.


 
 Of course. Everything in the brackets is const. That's what's brackets
 are for - precedence. C is in the brackets; C is const.


But x is outside brackets !  Why is it const, too ?


 I.e. the syntax for declaring reference to const is
 already in the language,


 
 You're going to have to clarify that, I'm afraid, as I don't
 understand. Are you referring to the function parameter syntax
 
     ref const(C) c
 
 ? In this case, c is indeed rebindable, but only because an extra
 level of indirection has been silently added.


When I write, "const(C) x;", I mean, "C is const but x is not."  This is 
semantically correct because the assignment operator works with the 
reference directly when an object of the same type is assigned.  It's in 
the language specs.  There is no problem for the assignment to check at 
compile time if the x itself is const or not.


 the question is, why it's not in the type
 system.


 
 I don't agree that that's even a reasonable question, because there is
 /not/ a syntax for "mutable reference to constant data" (not counting
 function parameters).


It could've been.  You wouldn't need to change the language syntax if 
you wanted to add one.

-- 
SnakE
Feb 17 2008
parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 18/02/2008, Sergey Gromov <snake.scaly gmail.com> wrote:

 When I write, "const(C) x;", I mean, "C is const but x is not."


That's just not getting it. x has type const(C), therefore x is const.

I say again, there is no way to express "mutable reference to const
data" in D, and any method you come up with to allow that would be (a)
incredibly confusing, and (b) would break generic programming and/or
the type system.

And ... you never need to do that anyway. There's always a different
way of writing the code.
Feb 17 2008
next sibling parent reply Derek Parnell <derek nomail.afraid.org> writes:
On Mon, 18 Feb 2008 07:12:08 +0000, Janice Caron wrote:


 I say again, there is no way to express "mutable reference to const
 data" in D


Of course you can. I do it all the time. But maybe I don't understand what
you are saying ;-)

import std.stdio;
class Foo
{
    const string _me;
    this(string name) { _me = name; writefln("Creating %s", _me); }    
}
void main()
{
   const(Foo) f;  // A mutable reference to const data.

   const(Foo) a = new Foo("one");
   const(Foo) b = new Foo("two");
   const(Foo) c = new Foo("three");
   
   f = a;
   f = b;
   f = c;
   
   writefln("%s", f._me);
   
}


What I can't get D to do easily is declare a const reference to mutable
data. Yes, I know there are ways to trick D to get around this but its not
as nice as just letting the programmer achieve their goals with simpler,
more intuitive syntax.

eg..
   const nonconst(Foo) f; // 'f' is const but it's data is not.

And I know the argument "But what purpose what that really serve?". The
answer to that is "doing it another way is more complex".

But anyhow, I know its not going to happen so my part in the discussion can
end here.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
18/02/2008 7:04:36 PM
Feb 18 2008
parent reply Denton Cockburn <diboss hotmail.com> writes:
On Mon, 18 Feb 2008 19:36:31 +1100, Derek Parnell wrote:


 On Mon, 18 Feb 2008 07:12:08 +0000, Janice Caron wrote:
 

 I say again, there is no way to express "mutable reference to const
 data" in D


 
 Of course you can. I do it all the time. But maybe I don't understand what
 you are saying ;-)
 
 import std.stdio;
 class Foo
 {
     const string _me;
     this(string name) { _me = name; writefln("Creating %s", _me); }    
 }
 void main()
 {
    const(Foo) f;  // A mutable reference to const data.
 
    const(Foo) a = new Foo("one");
    const(Foo) b = new Foo("two");
    const(Foo) c = new Foo("three");
    
    f = a;
    f = b;
    f = c;
    
    writefln("%s", f._me);
    
 }
 


That doesn't compile in 2.010
Feb 18 2008
parent Derek Parnell <derek psych.ward> writes:
On Mon, 18 Feb 2008 08:39:58 -0500, Denton Cockburn wrote:


 On Mon, 18 Feb 2008 19:36:31 +1100, Derek Parnell wrote:



 import std.stdio;
 class Foo
 {
     const string _me;
     this(string name) { _me = name; writefln("Creating %s", _me); }    
 }
 void main()
 {
    const(Foo) f;  // A mutable reference to const data.
 
    const(Foo) a = new Foo("one");
    const(Foo) b = new Foo("two");
    const(Foo) c = new Foo("three");
    
    f = a;
    f = b;
    f = c;
    
    writefln("%s", f._me);
    
 }
 


 
 That doesn't compile in 2.010


Damn! You're right. I was using an earlier version of D. However, if you
replace 'const(Foo)' with 'const(char)[]' is does compile. Which means that
a dynamic array, which is a reference type, can be mutable even though its
data is not.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Feb 18 2008
prev sibling parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Janice Caron <caron800 googlemail.com> wrote:

 I say again, there is no way to express "mutable reference to const
 data" in D, and any method you come up with to allow that would be (a)
 incredibly confusing, and (b) would break generic programming and/or
 the type system.


One can safely assume that a variable x of type int with a value 4 in it 
is a mutable reference to an object 4 of type invariant(int).  That is, 
all variables of primitive types in D (as well as in other languages) 
are either mutable or immutable references to invariant objects.

Class type variables in D are either mutable references to mutable 
objects, or immutable references to immutable objects.

Pointers are either mutable or immutable references to either mutable or 
immutable objects, except head-const variant.

Struct type variables are exactly like primitives if struct doesn't 
contain references somewhere.  I like to call them PODs.  Modifying a 
struct is generalised as replacing a reference to one immutable set of 
data with a reference to another immutable set of data, exactly as it is 
with primitive types.

Non-POD structs cannot be generalised as references.  Hence all the 
problems with them.

So, here is a table summarizing what current D constructs can do:

			ref		tgt
Primitive/POD:
			var		inv
			const		inv
			inv		inv
Class:
			var		var
			const		const
			inv		inv
Pointer:
			var		var
			var		const
			var		inv
			const		const
			const		inv
			inv		inv

The left column is a reference type, the right column is a type of 
referenced object.  As you can see, the most generic type is pointer.  
That's why you suggest using it here and there.  But it's not the D way.  
In D, the class reference should be the most generic.  It should be safe 
to assume everything is reference when you write a template.  The 
mutable references to const objects are not breaking generic 
programming, but aiding it.

-- 
SnakE
Feb 18 2008
parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 18/02/2008, Sergey Gromov <snake.scaly gmail.com> wrote:

 One can safely assume that a variable x of type int with a value 4 in it
 is a mutable reference to an object 4 of type invariant(int).


Not unless you've redefined the word reference.

At the ABI level, a reference is identical to a pointer. It occupies
four bytes of space (eight on a 64 bit machine), and those four bytes
contain an address. The difference between a reference and a pointer
occurs at the syntax level, not the ABI level.

What you've described there is not a reference at all - it's an int. A
reference to an int would occupy eight bytes of memory (four for the
reference, and four more for the int).
Feb 18 2008
next sibling parent reply Robert Fraser <fraserofthenight gmail.coim> writes:
Janice Caron Wrote:


 On 18/02/2008, Sergey Gromov <snake.scaly gmail.com> wrote:

 One can safely assume that a variable x of type int with a value 4 in it
 is a mutable reference to an object 4 of type invariant(int).


 
 Not unless you've redefined the word reference.
 
 At the ABI level, a reference is identical to a pointer. It occupies
 four bytes of space (eight on a 64 bit machine), and those four bytes
 contain an address. The difference between a reference and a pointer
 occurs at the syntax level, not the ABI level.
 
 What you've described there is not a reference at all - it's an int. A
 reference to an int would occupy eight bytes of memory (four for the
 reference, and four more for the int).


I _think_ he was trying to describe it from a logical, rather than
implementation standpoint. Logically, x "refers" (using the English term, not
the programming term, mind you) to 4. 4 can't be changed (you can't say 4 = 7),
but x can be.
Feb 18 2008
parent Sergey Gromov <snake.scaly gmail.com> writes:
Robert Fraser <fraserofthenight gmail.coim> wrote:

 Janice Caron Wrote:
 

 On 18/02/2008, Sergey Gromov <snake.scaly gmail.com> wrote:

 One can safely assume that a variable x of type int with a value 4 in it
 is a mutable reference to an object 4 of type invariant(int).


 
 Not unless you've redefined the word reference.
 
 At the ABI level, a reference is identical to a pointer. It occupies
 four bytes of space (eight on a 64 bit machine), and those four bytes
 contain an address. The difference between a reference and a pointer
 occurs at the syntax level, not the ABI level.
 
 What you've described there is not a reference at all - it's an int. A
 reference to an int would occupy eight bytes of memory (four for the
 reference, and four more for the int).


 
 I _think_ he was trying to describe it from a logical, rather than 
 implementation standpoint. Logically, x "refers" (using the English 
 term, not the programming term, mind you) to 4. 4 can't be changed (you 
 can't say 4 = 7), but x can be.


You're absolutely correct.

-- 
SnakE
Feb 18 2008
prev sibling parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Janice Caron <caron800 googlemail.com> wrote:

 On 18/02/2008, Sergey Gromov <snake.scaly gmail.com> wrote:

 One can safely assume that a variable x of type int with a value 4 in it
 is a mutable reference to an object 4 of type invariant(int).


 
 Not unless you've redefined the word reference.
 
 At the ABI level, a reference is identical to a pointer. It occupies
 four bytes of space (eight on a 64 bit machine), and those four bytes
 contain an address. The difference between a reference and a pointer
 occurs at the syntax level, not the ABI level.
 
 What you've described there is not a reference at all - it's an int. A
 reference to an int would occupy eight bytes of memory (four for the
 reference, and four more for the int).


I'm talking from the standpoint of generalization which you so much care 
about.  When I generalize, I don't care how things are implemented.  
It's behaviour that matters.  If I create an algorithm that uses 
references to invariant data, then it will work with anything that 
/behaves/ like such references.  Even if they are actually ints passed 
by value.

Imagine a language with only one class of objects, that is, objects 
passed by reference.  Integer numbers are invariant objects of type int, 
and an integer variable is a reference to an invariant object of type 
int.  Since the int objects are immutable, a compiler of this language 
can safely optimize the code and keep the int object values in place of 
references.  This is what D does.  It's an implementation detail.  It's 
an optimization which just happened to end up in language specs.  This 
optimization is so common that it's probably hard to believe that it's 
only an efficient implementation of a generic concept of a reference.

-- 
SnakE
Feb 18 2008
next sibling parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 18/02/2008, Sergey Gromov <snake.scaly gmail.com> wrote:

 I'm talking from the standpoint of generalization which you so much care
 about.


Well sure, but if you use a word to mean one thing, and I understand
it to mean something else, then we are not communicating.
Communication has failed, and we are not understanding each other.
Now, I'm no longer confident that I've got anything you've said, or
that you've got anything I've said. We may have been talking at
cross-purposes this whole thread.

When I discuss generalization, I need to be able to say/think "this is
how it's implemented for pointers; this is how it's implemented for
references; this is how...", and so on. If you redefine all the words,
then it just means we'll have to invent new ones in order to talk
properly about the ABI.

Ah well. No matter. :-)

For what it's worth, I was arguing exactly what you are arguing now
(that it should be allowable to modify the class reference of a const
class), several weeks back. But Walter patiently explained why it was
not a good idea, and his arguments were sound, so I got convinced. In
other words, this isn't a new argument - you might want to check out
some of that history (although I'm not sure I can advise on what to
search for - "const" would probably yeild rather too many hits!)
Feb 18 2008
parent reply Sean Reque <seanthenewt yahoo.com> writes:
 For what it's worth, I was arguing exactly what you are arguing now
 (that it should be allowable to modify the class reference of a const
 class), several weeks back. But Walter patiently explained why it was
 not a good idea, and his arguments were sound, so I got convinced. In
 other words, this isn't a new argument - you might want to check out
 some of that history (although I'm not sure I can advise on what to
 search for - "const" would probably yeild rather too many hits!)


Well if Walter wants people to use his language, he needs to do some better
convincing. I looked around and couldn't find anything searching around for 15
minutes. I liked D when I first learned about it, but I keep finding out things
that were "already discussed" that I'm still convinced are plain wrong, and
still haven't seen a good reason as to why they are right, which convinces me
more each time that D will never hit mainstream.
Feb 18 2008
parent reply Derek Parnell <derek nomail.afraid.org> writes:
 

 Well if Walter wants people to use his language, he needs to do some better
convincing.


I'm starting to suspect that in the effort to make the const system simple,
it has become simplistic.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
19/02/2008 9:26:28 AM
Feb 18 2008
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Derek Parnell wrote:

  

 Well if Walter wants people to use his language, he needs to do some better
convincing.


 
 I'm starting to suspect that in the effort to make the const system simple,
 it has become simplistic.


I'm ok with simplistic as long as simple, common things remain simple.

Don't know whether that's the case or not currently.

--bb
Feb 18 2008
parent reply "Janice Caron" <caron800 googlemail.com> writes:
 Don't know whether that's the case or not currently.


I've been using it for a while now, and on the whole I find it very
simple, elegant, and obvious.
Feb 18 2008
parent Derek Parnell <derek psych.ward> writes:
On Tue, 19 Feb 2008 07:29:18 +0000, Janice Caron wrote:


 Don't know whether that's the case or not currently.


 
 I've been using it for a while now, and on the whole I find it very
 simple, elegant, and obvious.


So long as one isn't trying to do things that Walter disagrees with.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Feb 19 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Sergey Gromov wrote:

 I'm talking from the standpoint of generalization which you so much care 
 about.  When I generalize, I don't care how things are implemented.  
 It's behaviour that matters.  If I create an algorithm that uses 
 references to invariant data, then it will work with anything that 
 /behaves/ like such references.  Even if they are actually ints passed 
 by value.


That's a good point, and a good reason why:

invariant(C)[] c;
invariant(int)[] i;

should both have immutable array contents, i.e. if the contents of a 
reference is invariant then the reference itself should be invariant.

The concept of having a mutable reference to immutable data is 
fundamentally flawed because it breaks the concept of what a reference 
is. A reference is not separable from what it refers to. If they were 
separable, they would be syntactically and semantically the same thing 
as pointers, and there would be no point whatsoever to even having a 
reference type.
Feb 19 2008
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Tue, 19 Feb 2008 12:49:09 -0800, Walter Bright wrote:


 invariant(C)[] c;
 invariant(int)[] i;
 
 should both have immutable array contents, i.e. if the contents of a 
 reference is invariant then the reference itself should be invariant.
 
 The concept of having a mutable reference to immutable data is 
 fundamentally flawed because it breaks the concept of what a reference 
 is. A reference is not separable from what it refers to. If they were 
 separable, they would be syntactically and semantically the same thing 
 as pointers, and there would be no point whatsoever to even having a 
 reference type.


Ok given this position and that 'string' is 'invariant(char)[]' then

   string s;  

makes 's' a reference to an immutable array, and thus 's' should also be
immutable, right? If so, does that mean that I cannot bind 's' to another
literal - that is change the bits in 's' such that the .ptr and maybe
.length properties have different values?

  string s = "abc'; // Initialized ok.
  s = "def";  // Should this fail because 
              // I'm now changing an immutable reference?

If your position re immutable references to hold, and if our codes needs
mutable 'references' to immutable data, and thus we need to use pointers,
what is the 'pointer' syntax for dynamic arrays that preserves array bounds
checking?

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Feb 19 2008
parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 19/02/2008, Derek Parnell <derek psych.ward> wrote:

 Ok given this position and that 'string' is 'invariant(char)[]' then

    string s;

 makes 's' a reference to an immutable array,


No, s is an array of immutable chars. Put another way, as I am sure
you are well aware, s is a value type, whose layout is

    struct
    {
        invariant(char)* ptr;
        uint length;
    }



 If so, does that mean that I cannot bind 's' to another
 literal


s isn't a reference, and so the concept of "binding" doesn't make
sense for it. What you can do is reassign it with another value.
Basically, everything works, exactly as is it should.
Feb 19 2008
parent Derek Parnell <derek nomail.afraid.org> writes:
On Tue, 19 Feb 2008 22:18:29 +0000, Janice Caron wrote:


 On 19/02/2008, Derek Parnell <derek psych.ward> wrote:

 Ok given this position and that 'string' is 'invariant(char)[]' then

    string s;

 makes 's' a reference to an immutable array,


 
 No, s is an array of immutable chars. Put another way, as I am sure
 you are well aware, s is a value type, ...


In that case, what did Walter really mean when he wrote:


That's a good point, and a good reason why:

invariant(C)[] c;
invariant(int)[] i;

should both have immutable array contents, i.e. if the contents of a 
reference is invariant then the reference itself should be invariant.






I took it that he was saying that 'c' and 'i' are references.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
20/02/2008 11:17:17 AM
Feb 19 2008
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Walter Bright" wrote

 Sergey Gromov wrote:

 I'm talking from the standpoint of generalization which you so much care 
 about.  When I generalize, I don't care how things are implemented.  It's 
 behaviour that matters.  If I create an algorithm that uses references to 
 invariant data, then it will work with anything that /behaves/ like such 
 references.  Even if they are actually ints passed by value.


 That's a good point, and a good reason why:

 invariant(C)[] c;
 invariant(int)[] i;

 should both have immutable array contents, i.e. if the contents of a 
 reference is invariant then the reference itself should be invariant.

 The concept of having a mutable reference to immutable data is 
 fundamentally flawed because it breaks the concept of what a reference is. 
 A reference is not separable from what it refers to. If they were 
 separable, they would be syntactically and semantically the same thing as 
 pointers, and there would be no point whatsoever to even having a 
 reference type.


So please explain this:

import std.stdio;

class C
{
    this(int n) {x = n;}
    int x;
}

void assignit(ref int src, ref int value)
{
       src = value;
}

void assignit(C src, C value)
{
       src = value;
}


void main()
{
    int n = 1;
    int m = 2;

    C c = new C(1);
    C d = new C(2);

    assignit(n, m);
    assignit(c, d);

    writefln("%s %s %s %s", n, m, c.x, d.x);
}

// outputs 2 2 1 2

In both cases, the assignit function is taking reference types as arguments. 
C is a reference type because it is a class.  ref int is a reference type 
because the compiler magically creates a reference.  Both do the same thing, 
but yet the class version doesn't result in the value changing, because we 
are rebinding the reference, not copying the class itself.  This is why your 
argument fails.  There are some cases in D where references are treated as 
non-rebindable pointers to data, where acting on the reference is equivalent 
to acting on the pointed at data, and then there are classes, where you can 
rebind the reference in some cases, but in other cases you are acting on the 
data pointed to.

I'm not saying that references should always be non-rebindable (I like the 
way classes work) or always be rebindable, I'm just saying that your 
argument against allowing references to be acted upon separate from the data 
is against the way the language/compiler currently is implemented.

You can make the case that class references are not the same as 
non-rebindable references, and also that they are not like pointers.  I 
would say that they are exactly like pointers except you cannot dereference 
them or perform general arithmetic on them.  This puts them in a category on 
their own, which I think is fair game to say that it is reasonable that we 
can ask for that category to be modified without affecting the consistency 
of the other categories.

The specific modification being that you can const-ify the data pointed to 
by a class reference without modifying the reference constness itself.

-Steve
Feb 19 2008
parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 19/02/2008, Steven Schveighoffer <schveiguy yahoo.com> wrote:

 So please explain this:

 <snip>
 // outputs 2 2 1 2


Simple. If you wanted the output to be 2 2 2 2 then the second
function should have
been declared

    void assignit(ref C src, ref C value)

But you missed out the "ref"s, and so src was merely a local copy.



 In both cases, the assignit function is taking reference types as arguments.


But in the second case, the reference is /local/. Function parameters
declared without "ref" are just local variables. Assigning src will
modify the local copy (of the reference), but you need the "ref"
keyword if you want to modify the original (reference).



 Both do the same thing,


No, they don't. Passing a value by reference is not the same thing as
passing a reference by value.
Feb 19 2008
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Janice Caron" wrote

 On 19/02/2008, Steven Schveighoffer wrote:

 So please explain this:

 <snip>
 // outputs 2 2 1 2


 Simple. If you wanted the output to be 2 2 2 2 then the second
 function should have
 been declared

    void assignit(ref C src, ref C value)

 But you missed out the "ref"s, and so src was merely a local copy.



 In both cases, the assignit function is taking reference types as 
 arguments.


 But in the second case, the reference is /local/. Function parameters
 declared without "ref" are just local variables. Assigning src will
 modify the local copy (of the reference), but you need the "ref"
 keyword if you want to modify the original (reference).



 Both do the same thing,


 No, they don't. Passing a value by reference is not the same thing as
 passing a reference by value.


You missed the point completely.  I'm not asking to find bugs in my code, 
I'm rebutting Walter's argument that "a reference is not separable from what 
it refers to".  If this was true in the current compiler, then I would 
expect the output to be 2 2 2 2, because assigning one reference to another 
should be like copying the value, right?

Walter's argument is like saying "If the sky wasn't green, then dragons 
wouldn't exist".  I'm not arguing his point about dragons, I'm saying, "wait 
a minute, the sky isn't green."

-Steve
Feb 19 2008
prev sibling parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Walter Bright <newshound1 digitalmars.com> wrote:

 The concept of having a mutable reference to immutable data is 
 fundamentally flawed because it breaks the concept of what a reference 
 is. A reference is not separable from what it refers to. If they were 
 separable, they would be syntactically and semantically the same thing 
 as pointers, and there would be no point whatsoever to even having a 
 reference type.


A reference refers to data which is outside of the reference's body.  
This is the concept.  A reference in a book, a C pointer, and a C++ 
reference are all realizations of this concept.  The reason for C++ 
references to be immutable is obvious: the C++ designers wanted the 
C::operator=(C&) to work.

D supports mutable references, so D references are not C++ references.  
D references are not the same as the data they refer to.  They are much 
closer to pointers than in C++.

The difference is in syntax.  The point in having references in the 
language is the same as in C++: to use the same syntax for accessing 
objects, their members, and primitive types.  This is required for 
proper generalization, and also simplifies program code.

This is why references must support all possible type variants: they are 
instruments of generalization, so power of D templates depends directly 
on the power of references.

-- 
SnakE
Feb 19 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Sergey Gromov wrote:

 Walter Bright <newshound1 digitalmars.com> wrote:

 The concept of having a mutable reference to immutable data is 
 fundamentally flawed because it breaks the concept of what a reference 
 is. A reference is not separable from what it refers to. If they were 
 separable, they would be syntactically and semantically the same thing 
 as pointers, and there would be no point whatsoever to even having a 
 reference type.


 
 A reference refers to data which is outside of the reference's body.  
 This is the concept.  A reference in a book, a C pointer, and a C++ 
 reference are all realizations of this concept.  The reason for C++ 
 references to be immutable is obvious: the C++ designers wanted the 
 C::operator=(C&) to work.
 
 D supports mutable references, so D references are not C++ references.  
 D references are not the same as the data they refer to.  They are much 
 closer to pointers than in C++.
 
 The difference is in syntax.  The point in having references in the 
 language is the same as in C++: to use the same syntax for accessing 
 objects, their members, and primitive types.


That is only a small part of why D classes are reference types. The 
major reason is that polymorphism doesn't work for value types, it cries 
out for reference types. Value and reference types have different uses.


 This is required for 
 proper generalization, and also simplifies program code.
 
 This is why references must support all possible type variants: they are 
 instruments of generalization, so power of D templates depends directly 
 on the power of references.
Feb 19 2008
parent Sergey Gromov <snake.scaly gmail.com> writes:
Walter Bright <newshound1 digitalmars.com> wrote:

 Sergey Gromov wrote:

 Walter Bright <newshound1 digitalmars.com> wrote:

 The concept of having a mutable reference to immutable data is 
 fundamentally flawed because it breaks the concept of what a reference 
 is. A reference is not separable from what it refers to. If they were 
 separable, they would be syntactically and semantically the same thing 
 as pointers, and there would be no point whatsoever to even having a 
 reference type.


 
 A reference refers to data which is outside of the reference's body.  
 This is the concept.  A reference in a book, a C pointer, and a C++ 
 reference are all realizations of this concept.  The reason for C++ 
 references to be immutable is obvious: the C++ designers wanted the 
 C::operator=(C&) to work.
 
 D supports mutable references, so D references are not C++ references.  
 D references are not the same as the data they refer to.  They are much 
 closer to pointers than in C++.
 
 The difference is in syntax.  The point in having references in the 
 language is the same as in C++: to use the same syntax for accessing 
 objects, their members, and primitive types.


 
 That is only a small part of why D classes are reference types. The 
 major reason is that polymorphism doesn't work for value types, it cries 
 out for reference types. Value and reference types have different uses.


My argument was not about references vs values but about references vs 
pointers.  I'm arguing about this statement:


 If they (references---S.G.) were 
 separable, they would be syntactically and semantically the same thing 
 as pointers, and there would be no point whatsoever to even having a 
 reference type.






Pointers, being a flavour of references, support polymorphism, too.  The 
only difference from pointers is in syntax, and it is very important.  
The value types are different, or more precisely, as I've written 
earlier, any value type not containing references may be abstracted as a 
mutable reference to immutable data.


 This is required for 
 proper generalization, and also simplifies program code.
 
 This is why references must support all possible type variants: they are 
 instruments of generalization, so power of D templates depends directly 
 on the power of references.




-- 
SnakE
Feb 20 2008
prev sibling next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 16/02/2008, none <z gg.com> wrote:

 What I mean is in C++, you can define 2 different kinds of C++ pointers:
 Sorry in C++, it should be

 (1) C* const b;  // b can be re-bind, but the object cannot be modified

 (2) const C* b and const C* const b;  // both pointer, and data are const.


I think you mistyped. (1) means "b is a const pointer to mutable
data". In this case, therefore, b cannot be rebound. That would not be
allowed in D because it breaks transitivity. On the other hand, the
sentiment you expressed: "b can rebind, but the object cannot be
modifed", can be expressed in both C++ and D as

    C const * b // C++
    const C * b // C++, alternative syntax
    const(C)* b // D

"Both pointer and data are const" can be written in both languages as

    C const * const b // C++
    const C * const b // C++, alternative syntax
    const C* b; // D
    const(C*) b; // D, alternative syntax

Both of my D examples assumed that the object C has been declared as a
struct (in D), because otherwise you can't make an equivalence with
C++. If C had been declared as a class in D, then things look a little
different

    auto b = new C; // D

There is no exact equivalent built into C++, although you can
construct one artificially.

    C& b = *(new C()); // C++

This b will now behave just like a D reference. the C instance is on
the heap, as required, and b is on the stack and four bytes big, as
required. Now let's see what kind of constancy you can get:

    (1) C& b = ...
    (2) C& const b = ...
    (3) C const & b = ...
    (4) C const & const b =

What may not be immediately obvious is that (1) and (2) are completely
identical, because references in C++ are /always/ const. Likewise, (3)
and (4) are completely identical, for the same reason.

You absolutely /cannot/ do "mutable reference to const data" in C++.
It's impossible. The best you can do is "mutable pointer to const
data", and you /can/ do that in D. We're not missing out here!
Feb 16 2008
prev sibling parent reply none <z gg.com> writes:
 == Quote from Janice Caron (caron800 googlemail.com)'s article

 But I just want to clear up one misconception. You /cannot/ do that in
 C++. References in C++ are /never/ rebindable.


 That's a terminology issue, to make it clear:
 class C {}
 D                           C++
 =========================   ===========================
 reference: C c = new C();   pointer:    C *c = new C();
 pointer:   C* cp = &c;      ptr-to-ptr: C **cp = &c;


I just want to make it clear again, nobody has what you called 'misconception'.

By using my table, I'm saying '_reference_ in D is similar to _pointer_ in C++'!

I think you have a 'misconception' that '_reference_ in D is similar to
_reference_ in C++'!

Just as you said: "References in C++ are /never/ rebindable"; but '(non-const)
reference in D' is rebindable

class C {}
C c;
c = c1;
c = c2;  // rebind!

So '_reference_ in D is similar to _pointer_ in C++', not reference in C++!

Since 'in C++, const C* p; // non-const pointer, const data' is allowed, why
cannot we have 'non-const reference, const data' in D?
Feb 17 2008
parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 17/02/2008, none <z gg.com> wrote:

 So '_reference_ in D is similar to _pointer_ in C++', not reference in C++!


I disagree. I say a pointer is a pointer is a pointer, and that a
pointer in C++ is similar (nay, identical) to a pointer in D.


 Since 'in C++, const C* p; // non-const pointer, const data' is allowed, why
 cannot we have 'non-const reference, const data' in D?


Why not just substitute your C++ pointer with a D pointer?

If it's acceptable to use a pointer in C++, then use the same pointer in D.
Feb 17 2008
parent reply Matti Niemenmaa <see_signature for.real.address> writes:
Janice Caron wrote:

 On 17/02/2008, none <z gg.com> wrote:

 Since 'in C++, const C* p; // non-const pointer, const data' is allowed, why
 cannot we have 'non-const reference, const data' in D?


 
 Why not just substitute your C++ pointer with a D pointer?
 
 If it's acceptable to use a pointer in C++, then use the same pointer in D.


The difference is that in C++, 'new C' results in a C*, whereas in D it results 
in a C. Assuming C is a class, that is.

So the C++ code "C* a = new C();" converts to the D code "C a = new C;".

Now what he wants is to convert the C++ "const C* b = a;" to D "??? b = a;"
with 
the semantics that b can be reassigned but the data behind it is unchangeable.

I.e.:

class Foo { public: int x; };

int main() {
	Foo* a = new Foo();
	const Foo* b = a;
	/* here, G++ gives "error: assignment of data-member 'Foo::x' in read-only 
structure" */
	b->x = 1;
	delete a;
}

Would become what, exactly, in D? (Disclaimer: I honestly don't know, but
that's 
what I think he's asking for.)

-- 
E-mail address: matti.niemenmaa+news, domain is iki (DOT) fi
Feb 17 2008
parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 17/02/2008, Matti Niemenmaa <see_signature for.real.address> wrote:

 Now what he wants is to convert the C++ "const C* b = a;" to D "??? b = a;"
with
 the semantics that b can be reassigned but the data behind it is unchangeable.


OK, I see that.

But the thing is, it is never actually /necessary/ to do that. It is
always possible to just write the code differently. There is really no
pressing /need/ for "const class with mutable reference", since nobody
has ever demonstrated a real-life use case that couldn't just be done
differently. Certainly, no need pressing enough to demand a major
change to generic programming and the type system.

Also, remember that a C++ class is a D struct, and there's really no
equivalent to a D class in C++.
Feb 17 2008
next sibling parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= writes:
Janice Caron schrieb:

 On 17/02/2008, Matti Niemenmaa <see_signature for.real.address> wrote:

 Now what he wants is to convert the C++ "const C* b = a;" to D "??? b = a;"
with
 the semantics that b can be reassigned but the data behind it is unchangeable.


 
 OK, I see that.
 
 But the thing is, it is never actually /necessary/ to do that. It is
 always possible to just write the code differently. There is really no
 pressing /need/ for "const class with mutable reference", since nobody
 has ever demonstrated a real-life use case that couldn't just be done
 differently. Certainly, no need pressing enough to demand a major
 change to generic programming and the type system.
 
 Also, remember that a C++ class is a D struct, and there's really no
 equivalent to a D class in C++.


Show me how I can maintain a simple map of class instances, which I get as 
const(C) from somewhere else, i.e. I have to accept the const here.

example:

const(C)[string] map;

<- completely useless - you can do nothing with this construct

The only possibility to solve this is to either use a cast or to use a struct S 
{ const(C) obj } and modify the map to S*[string] (or something similar) - at 
least I don't see an alternative.

This, of course, would also apply to some self-made map-like container.
Feb 17 2008
parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 17/02/2008, Sönke Ludwig <ludwig informatik_dot_uni-luebeck.de> wrote:

 Show me how I can maintain a simple map of class instances, which I get as
 const(C) from somewhere else, i.e. I have to accept the const here.

 example:

 const(C)[string] map;

 <- completely useless - you can do nothing with this construct


So change it to

    const(C)*[string] map;

Now you've a map of mutable pointers, indexed by string. It's not hard.



 or to use a struct S { const(C) obj }


That probably won't work in the future. You're basically exploiting a
bug there, and I imagine that soon it will be fixed.
Feb 17 2008
next sibling parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= writes:
Janice Caron schrieb:

 On 17/02/2008, Sönke Ludwig <ludwig informatik_dot_uni-luebeck.de> wrote:

 Show me how I can maintain a simple map of class instances, which I get as
 const(C) from somewhere else, i.e. I have to accept the const here.

 example:

 const(C)[string] map;

 <- completely useless - you can do nothing with this construct


 
 So change it to
 
     const(C)*[string] map;
 
 Now you've a map of mutable pointers, indexed by string. It's not hard.


Since C is a class, const(C)* will mean a mutable pointer to a const class
reference, which is not even allocatable with a simple syntax (was brought
up here a while ago), also this would be an additional allocation, just
like with the struct workaround (see below).

Generally, I think that it is very desirable to be able to handle the
reference/pointer part of a class C separate from the actual data in this
respect. After all they are completely distinct in the underlying
implementation.


 
 

 or to use a struct S { const(C) obj }


 
 That probably won't work in the future. You're basically exploiting a
 bug there, and I imagine that soon it will be fixed.
 


No, was talking about creating a struct where the const reference stored on
the heap - a mutable pointer to this struct is then stored in the map.
If a new object is to replace an array entry, a new struct is allocated
and a pointer to this new struct replaces the old one.

Sorry, forgot an example - this is what I was thinking about:
struct S { const(C) inst; }
S*[string] map;
map["hello"] = new S(someinst);

All of this is and should always be possible, it does not break any
const principle or anything. It's just that it requires an additional
heap allocation and a lot of additional typing which should really not
be necessary for such a basic thing.
Feb 18 2008
parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= writes:
Sorry, the "new S(someinst)" syntax will not work, of course.
But you get the drift..
Feb 18 2008
prev sibling parent Robert Fraser <fraserofthenight gmail.coim> writes:
Janice Caron Wrote:

 So change it to
 
     const(C)*[string] map;
 
 Now you've a map of mutable pointers, indexed by string. It's not hard.
 


I don't feel good about sacrificing performance for something that I've lived
without my whole programming career. The syntax is uglier, too.

Your argument "we don't need it; there's always a workaround" is complete
bollocks. We don't need high-level native-compiled languages at all, anything
we can do in C or D we can in assembly language. We choose to use them because
they encourage a more structured programming style with abstracted syntax. What
you're basically encouraging is "workaround-oriented programming."
Feb 18 2008
prev sibling parent Sean Reque <seanthenewt yahoo.com> writes:
 On 17/02/2008, Matti Niemenmaa <see_signature for.real.address> wrote:

 Now what he wants is to convert the C++ "const C* b = a;" to D "??? b = a;"
with
 the semantics that b can be reassigned but the data behind it is unchangeable.


 
 OK, I see that.
 
 But the thing is, it is never actually /necessary/ to do that. It is
 always possible to just write the code differently. There is really no
 pressing /need/ for "const class with mutable reference", since nobody
 has ever demonstrated a real-life use case that couldn't just be done
 differently. Certainly, no need pressing enough to demand a major
 change to generic programming and the type system.


Having a const class with mutable reference makes the language much much
cleaner. The D docs themselves state that D is designed so that the programmer
should rarely have to dip down to the level of pointers. Yet here we have a
very important feature, const, that when used with an object reference cripples
the reference so that it can no longer point to anything else, requiring us to
use pointers when references should be able to suffice.

D references are like Java references, and D const has similiarities with C++
const. I don't see why it should be so hard to mix Java-style references with
C++ const, especially since Java style references are nothing more  than
syntactically pleasing pointers.
Feb 17 2008
prev sibling next sibling parent reply Sean Reque <seanthenewt yahoo.com> writes:
 So why can't we have both (just as in C++):
 
 ========================
 const B b;  // b cannot be re-bind, and the object cannot be modified
 B const b;  // b can    be re-bind, but the object cannot be modified
 ========================


The saddest part of this is it actually worked this way at least up through
2.007. I compiled the following code in a 2.007 compiler and when it worked,
thought that everyone was crazy. Then I downloaded the 2.010 compiler and it
wouldn't compile. So it's not even a matter of it being a lot of work to make
it happen. I think everyone who is interested in having const work the older
way should make keep making themselves heard!

import std.stdio;

class C {
}

int main() {
	C c1 = new C();
	C c2 = new C();
	const(C) cc = c1;
	cc = c2; 		// compiles with 2.007, but not 2.010
	writeln("done!");
	return 0;
}
Feb 18 2008
parent "Craig Black" <craigblack2 cox.net> writes:
"Sean Reque" <seanthenewt yahoo.com> wrote in message 
news:fpc5o0$2djh$1 digitalmars.com...

 So why can't we have both (just as in C++):

 ========================
 const B b;  // b cannot be re-bind, and the object cannot be modified
 B const b;  // b can    be re-bind, but the object cannot be modified
 ========================


 The saddest part of this is it actually worked this way at least up 
 through 2.007. I compiled the following code in a 2.007 compiler and when 
 it worked, thought that everyone was crazy. Then I downloaded the 2.010 
 compiler and it wouldn't compile. So it's not even a matter of it being a 
 lot of work to make it happen. I think everyone who is interested in 
 having const work the older way should make keep making themselves heard!

 import std.stdio;

 class C {
 }

 int main() {
 C c1 = new C();
 C c2 = new C();
 const(C) cc = c1;
 cc = c2; // compiles with 2.007, but not 2.010
 writeln("done!");
 return 0;
 }


When the latest const system became final, I was a little disappointed, but 
I was like "whatever".  This stuff has been debated way too much and frankly 
I'm sick of hearing about it.  Although I don't think it's going to change 
anything, I agree with you.  Without this feature (whatever the syntax used 
to express it) the const system is simply incomplete.

-Craig
Feb 18 2008
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"none" wrote

 Why can't we define re-assignable const reference variable?
 i.e. the variable can be re-bind, but it's allowed to change the object it
 points to:


The problem here, none (is that your real name?), is that Walter has tried 
several times to achieve exactly that, and each time the syntax that he has 
created is either confusing or breaks something else.  I think he has given 
up, claiming that there is no way to do it, but I think he is wrong in that 
respect.

The problem stems from the fact that classes are inherently references and 
everything else is not.  This in itself is not a problem, and is a 
distinction I happen to agree with, but the issue is that there is no easy 
way to const-modify the data of a class without also modifying the reference 
to the data.  In order for this to work, there needs to be a syntax change.

In all the responses to this thread, there is one point of view that I wish 
to rebut:

"You can't have mutable references to const classes because any syntax 
change you have to make would break generic programming"

Generic programming is already broken.  That is, because classes *are* 
references and must be created from the heap using the new operator, you 
must treat them differently today than other types.  For example, if I want 
to create a generic type that creates a new version of a type, or uses an 
array of the type, depending on whether the type is a class or a struct or 
something else, I need to use static if to determine this before creating 
the new type.

I believe others have pointed out other examples, but it all comes down to 
the fact that yes, classes are inherently different than structs or other 
data types, and you have to treat them differently, so saying you cannot 
change the language because then you'd have to treat classes differently 
than other types is asinine.

I have proposed two syntax changes that I believe would resolve the problem. 
One is to allow dereferencing a class type, such as:

const(*C)* c;

Which would translate to *C being the value of type C, and therefore 
const(*C)* being exactly what we want.  This does not add any keywords, and 
also utilizes the * operator in familiar ways, and so it would be in my mind 
trivial to introduce and implement in the compiler.  The only issue is that 
you must restrict the user from declaring a variable or return type of the 
dereferenced class type.  i.e.:

*C cvalue;

would be illegal.

The only drawback here is that code is going to get really ugly, but I can 
live with this because we can make templates that make the code look better. 
And in fact, this *fixes* to some degree the difference between classes and 
structs for generic programming, because if you want a reference type, you 
can do:

valuetype(T)
{
   static if(is(T == class))
      alias *T valuetype;
   else
      alias T valuetype;
}

struct hasTailconstRef(T)
{
    const(valuetype!(T)) * myref;
}

now, hasTailconstRef.myref is a tailconst reference to a type no matter if 
the type is a class, struct, int, or whatever.

The other proposal I have made, which I like better but would be a more 
drastic syntax change, is to have a reference operator that "pulls out" the 
reference on a class.  Other types would be treated like references to the 
type:

struct S {}
class C {}

S & s; // equivalent to S * s
C & c; // equivalent to C c
int & i; // equivalent to int * i

With this, you can then use the & operator to declare a tailconst reference 
to a class or struct equivalently:

const(C) & c;
const(S) & s;

I have never read any arguments that correctly refute that these options 
would work.  All I have ever heard is the generic programming argument, 
which is totally bogus, and "we've already tried tail-const, it doesn't 
work", which isn't an argument at all.

I challenge anyone to tell me why either of these schemes would not work.

-Steve
Feb 19 2008
parent reply Yigal Chripun <yigal100 gmail.com> writes:
here's my random thought on the subject (just wanted to throw those in
the mix...):
[warning: long post ahead]

the current (and all previous) const designs fail due to too narrow a
view on the issue.
when introducing a const system to a language than the language as a
whole should be examined and related concepts should be tweaked
accordingly. So here's my list of those related issues:

references -
in a high level language like D you should be able to just use refs
everywhere and pointer usage should be discouraged.  D as a systems
programming language, should however provide pointers for those
/advanced/low-level/potentially unsafe uses when you do systems
programming. that means that refs should be enhanced in D and pointers
should be used _only_ when truly you need them (for example for pointer
arithmetic).
for example: you should be able to use (and it should be the preferred
way!):
ref S s1 = new S(); // S is a struct
instead of the equivalent:
S* s2 = new S();
so you can eliminate pointers from almost all user code.
how does this affect const?
i suggest the following:
const(T) t = new T(); // this would be a mutable ref to const T
const(ref T) t = new T(); // this would be a const ref to const T
and you can also define "const T" as a shortcut for "const(ref T)"
i know that this means const(T) isn't the same as "const T" but I think
that this is a reasonable compromise (if it's consistent for all types)
another issue with refs is that i want to be able to return the lvalue
by specifying the return type to be ([const] ref T).

another  issue is a function call -
there are really only two modes for passing a parameter to a function:
1. you allow the function to change the outside(actual) parameter
2.  you do not allow the function to do that.
value vs. ref semantics is an implementation detail that user level code
shouldn't care about at all, and a special syntax should be provided and
used to distinguish the two only for advanced use cases.
so for example you could define:
void func_name(in T t);
in the above example the in keyword would represent the fact that you
cannot change the outside parameter.
how do you implement it? the compiler should have a very simple
heuristic that says that if T is a primitive value or a small struct
than just pass it by value and if it's a class instance than pass it as
a const ref. that is an optimization the compiler should provide.
now, what if i want to explicitly choose the parameter passing
semantics? that is also possible (but discouraged for user level code)
with a bit more verbose code and language rules. for example primitives
should be passed by value be default and you can change that with a ref
keyword. class instances are passed by ref so you can pass them by value
if they implement a dup method, and the user must call that explicitly.
so, other_func(someClassInstance.dup()); passes someClassInstance by value.
the second mode above is simply pass T by ref. also a bigger change
could be done so that the default mode when passing parameters is 1. so
you won't need to specify in and it would be implied.

for generic programming to work it needs to use the above "in" and "ref"
(i.e. modes 1 and 2) and not rely on a specific parameter passing
semantics unless this is what needed.

one last thing: i really liked oskar's orthogonal const proposal and
wish for it to be further explored.

anyway, that is just my shnekel (2 NIS) that i wanted to add to the
discussion.

--Yigal
Feb 19 2008
parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Yigal Chripun <yigal100 gmail.com> wrote:

 i suggest the following:
 const(T) t = new T(); // this would be a mutable ref to const T
 const(ref T) t = new T(); // this would be a const ref to const T
 and you can also define "const T" as a shortcut for "const(ref T)"
 i know that this means const(T) isn't the same as "const T" but I think
 that this is a reasonable compromise (if it's consistent for all types)
 another issue with refs is that i want to be able to return the lvalue
 by specifying the return type to be ([const] ref T).


Please, why invent new syntax ?

const(T) t;	// mutable ref to const T
const{T t;}	// const ref to const T, because of transitiviness

This syntax even worked in one of the previous compiler versions!

-- 
SnakE
Feb 19 2008
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Sergey Gromov" wrote

 Please, why invent new syntax ?

 const(T) t; // mutable ref to const T
 const{T t;} // const ref to const T, because of transitiviness

 This syntax even worked in one of the previous compiler versions!


Yes, this is one of the trials of Walter to see if he could get tail-const 
to work.

The problem is if T is not a reference/pointer (such as int).  Now:

const(T) t;
T t;

are equivalent, which is necessary to make that const system work.  To have 
some variable declared as const(T), and then allow assignment to that 
variable is completely inconsistent with the fundamental usage of 
parentheses.  If you have something defined as f(x), the entirety of x 
should be affected by f.  This is why that system was dropped, as it should 
have been.

-Steve
Feb 19 2008
parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Steven Schveighoffer <schveiguy yahoo.com> wrote:

 "Sergey Gromov" wrote

 Please, why invent new syntax ?

 const(T) t; // mutable ref to const T
 const{T t;} // const ref to const T, because of transitiviness

 This syntax even worked in one of the previous compiler versions!


 
 Yes, this is one of the trials of Walter to see if he could get tail-const 
 to work.
 
 The problem is if T is not a reference/pointer (such as int).  Now:
 
 const(T) t;
 T t;
 
 are equivalent, which is necessary to make that const system work.  To have 
 some variable declared as const(T), and then allow assignment to that 
 variable is completely inconsistent with the fundamental usage of 
 parentheses.  If you have something defined as f(x), the entirety of x 
 should be affected by f.  This is why that system was dropped, as it should 
 have been.


If you create a generic algorithm which works with T, and declare 
something as

const(T) t;

then you effectively assert that you're going to replace t with 
different other Ts, but promise to keep integrity of a referenced T 
intact, if anything is referenced at all.  This means that for int, 
which is not referencing anything,

const(int) t;

is completely and safely equivalent to

int t;

without breaking any contracts of your algorithm.  Please provide an 
example where "const(int) x;" absolutely must mean "const int x;" for a 
generic algorithm to work properly.

-- 
SnakE
Feb 20 2008
next sibling parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 20/02/2008, Sergey Gromov <snake.scaly gmail.com> wrote:

 This means that for int,
 which is not referencing anything,

 const(int) t;

 is completely and safely equivalent to

 int t;


Sergey, there may well be merit in the idea of having some form of
syntax which implies rebindable const classes. I'm not necessarily
against the idea. However, I most wholeheartedly /am/ against allowing
any kind of move which suggests that const(int) shall mean mutable
int!

One of the reasons that that syntax was ditched was because it was
damnably confusing, and got many, many complaints from people who were
using it. Not only did const(int) mean "mutable int", but even if you
could get your head round that one, it turned out that

    const (int *)* p;

and

    const (int **) p;

were completely equivalent. And I have absolutely no idea what the
syntax for array of const ints was. Was it "const(int)[]"? Was it
something else? I mean, it was just too confusing for words. No way
can we /ever/ go back to that. For any type, T, const(T) absolutely
/must/ mean that T is const.

So ... if you want widespread, across-the-board support for rebindable
class references, please, please, please choose a different syntax to
campaign for. Several syntaxes have been suggested in the past,
including

    const(T)& /* by me */
    ref const(T)
    const(*T)*
    tailconst(T)
    TailConst!(T)

and so on, any or all of which could work, if Walter finds a way to
make it possible. But not const(T). Anything else, just not const(T).
Feb 20 2008
parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Janice Caron <caron800 googlemail.com> wrote:

 On 20/02/2008, Sergey Gromov <snake.scaly gmail.com> wrote:

 This means that for int,
 which is not referencing anything,

 const(int) t;

 is completely and safely equivalent to

 int t;


 
 [...]
 One of the reasons that that syntax was ditched was because it was
 damnably confusing, and got many, many complaints from people who were
 using it. Not only did const(int) mean "mutable int", but even if you
 could get your head round that one, it turned out that
 
     const (int *)* p;
 
 and
 
     const (int **) p;
 
 were completely equivalent.


Pointers ruin my beautiful theory.  :-)

They are different.  They do not generalize with references.  So I 
propose to outlaw them completely: let them be an advanced, unsafe, low-
level feature.  So that pointers can never be const, and an explicit 
cast is /always/ required to convert from reference to pointer and back.

To do this, references must be powerful enough to replace pointers for 
any high-level tasks.  For instance, structs should always be passed by 
reference unless they are invariant and small.


 And I have absolutely no idea what the
 syntax for array of const ints was. Was it "const(int)[]"? Was it
 something else?


Easy.  An array of const ints is "const(int[]) x;"  You can't change 
ints, you can't change length nor ptr either.  You can replace the whole 
thing though because x is not const (is outside the parentheses).


 I mean, it was just too confusing for words. No way
 can we /ever/ go back to that. For any type, T, const(T) absolutely
 /must/ mean that T is const.


My concept is very simple.  Everything within the scope of const is 
const, everything outside is not.

The confusion arises in two cases:

a) trying to apply constness to primitive types.  It really may be hard 
to understand why const(int) does nothing.  But you don't need to use 
this syntax in everyday programming.  What you really need is const(T) 
to behave consistently for different T.  C++ allows to call a destructor 
for int for exactly the same reason, and

b) when you use const for pointers and experience completely different 
behaviour from references.  This is because pointers are too different, 
and you can't do without pointers in D at the moment.  This should be 
fixed.

-- 
SnakE
Feb 20 2008
parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 20/02/2008, Sergey Gromov <snake.scaly gmail.com> wrote:

  > I mean, it was just too confusing for words. No way
  > can we /ever/ go back to that. For any type, T, const(T) absolutely
  > /must/ mean that T is const.

 My concept is very simple.  Everything within the scope of const is
  const, everything outside is not.


Not good enough. Everything inside the /brackets/ must be const.
Otherwise, don't call it const, call it something else. Call it
"tailconst" or "rebindable" or whatever, but don't call it const,
because it isn't.

I want to be able to introduce newbies to D and tell them how
wonderful it is. I can't do that if const(T) doesn't mean const T.
Really.

Back it D2.007 - the version of const that you like, but most people
didn't, we had five different kinds of const. Count them. Five. They
were:

    final T // head const
    const(T) // tail const
    const T // fully const
    invariant(T) // tail invariant
    invariant T // fully invariant

...and that's not counting the use of "in" in function declarations.
It was just too silly for words.

Right now, in D2.011, "invariant(char)[]" is a string. That makes
absolutely perfect sense. Long may that remain.

What is your problem with just choosing a different word, or a
different syntax? You'd get a lot more support for the idea that way.
I certainly wouldn't be arguing with you in that case.
Feb 20 2008
parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Janice Caron <caron800 googlemail.com> wrote:

 On 20/02/2008, Sergey Gromov <snake.scaly gmail.com> wrote:

  > I mean, it was just too confusing for words. No way
  > can we /ever/ go back to that. For any type, T, const(T) absolutely
  > /must/ mean that T is const.

 My concept is very simple.  Everything within the scope of const is
  const, everything outside is not.


 
 Not good enough. Everything inside the /brackets/ must be const.
 Otherwise, don't call it const, call it something else. Call it
 "tailconst" or "rebindable" or whatever, but don't call it const,
 because it isn't.
 
 I want to be able to introduce newbies to D and tell them how
 wonderful it is. I can't do that if const(T) doesn't mean const T.
 Really.


I am a newbie.  I want consistency in the language.  This is what 
attracts me.


 Back it D2.007 - the version of const that you like, but most people
 didn't, we had five different kinds of const. Count them. Five. They
 were:
 
     final T // head const
     const(T) // tail const
     const T // fully const
     invariant(T) // tail invariant
     invariant T // fully invariant


Can't see anything wrong here.  Except that you omit the variable for 
some reason.  Const only has meaning when applied to a reference.  So:

	const(T) x;	// tail const
	const{T x;}	// full const

Simple.  Clean.


 ...and that's not counting the use of "in" in function declarations.
 It was just too silly for words.


As a newbie, I was really confused by a number of ways one can specify 
constness of an argument.  This deserves a separate post.  What I'm sure 
of, no "const," "const{}" or "const:" should be allowed there which all 
are different forms of a const attribute.

Note that my confusion was about 2.010 which you probably consider 
'fixed.'


 Right now, in D2.011, "invariant(char)[]" is a string. That makes
 absolutely perfect sense. Long may that remain.


Can't see any sense in making ptr and length variable.  This makes 
strings 'somewhat const' to me.  Not really const.


 What is your problem with just choosing a different word, or a
 different syntax? You'd get a lot more support for the idea that way.
 I certainly wouldn't be arguing with you in that case.


Actually, const() syntax is already different from const attribute.  
Probably if we had a tailconst attribute instead, so that it was 
possible to write

tailconst
{
	C c;
	int x;	// either illegal, or not affected
}

this would be quite enough, and pretty consistent.  This should of 
course deprecate the use of non-attribute const() form.  But it would 
have a strange effect for structs anyway: with "tailconst S s;", which 
in my syntax is "const(S) s;", you won't be able to "s.whatever = 
newValue", but it would be legal to

	tailconst S s = initializer;
	S var = s;	// contents copied
	var.whatever = newValue;
	s = var;	// legal for tailconst

otherwise generic algorithms won't work.

I see your main concern is educational.   This is resolved very simple, 
too: teach that /everything/ in D are objects, and everything is by 
reference.  But compiler resolves many of the references at compile 
time.  This is not strictly true because most references are resolved at 
language design time, but it doesn't invalidate the thesis itself.

-- 
SnakE
Feb 20 2008
next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 20/02/2008, Janice Caron <caron800 googlemail.com> wrote:

  If you want the array also to be invariant - no problemo! Just put the
  array inside the brackets too - "invariant(char)[]".


That was a typo. Allow me to correct myself.

If you want the array also to be invariant - no problemo! Just put the
array inside the brackets too - "invariant(char[])".
Feb 20 2008
prev sibling parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 20/02/2008, Sergey Gromov <snake.scaly gmail.com> wrote:

 Const only has meaning when applied to a reference.


Hardly. Const is perfectly meaningful when applied to a value!


 So:

         const(T) x;     // tail const
         const{T x;}     // full const

  Simple.  Clean.


Yuk! Fortunately, I just don't believe Walter will go for that.


  > Right now, in D2.011, "invariant(char)[]" is a string. That makes
  > absolutely perfect sense. Long may that remain.

 Can't see any sense in making ptr and length variable.  This makes
  strings 'somewhat const' to me.  Not really const.


Well then you really haven't understood it all. The characters of a
string may be stored in a ROM segment, and for that reason, the
characters of a string may not be modified. But there is no reason why
you can't modify slices which merely point into that ROM data.

Don't you see that "invariant(char)" means exactly that!? Chars that
are invariant - it doesn't get much simpler. And "[]" means "array
of". Hence, "invariant(char)[]" = "array of invariant chars".

If you want the array also to be invariant - no problemo! Just put the
array inside the brackets too - "invariant(char)[]".

I'm not describing anything exotic here - I'm describing the system as
it is now - simple, elegant, and obvious.



 Actually, const() syntax is already different from const attribute.


Again, you're wrong. The following two lines

    const int x;
    const(int)x;

are identical in meaning. And that remains true for any type, no
matter how complicated, e.g.

    const int[]* p;
    const(int[]*)p;

Again, completely identical. You are partly correct in that "const"
/when applied to member functions/ means something different, and that
is something which bugs me a little. But member functions aside, the
const attribute just makes things const, which is exactly what you'd
expect.


  Probably if we had a tailconst attribute instead, so that it was
  possible to write

  tailconst
  {
         C c;
         int x;  // either illegal, or not affected
  }


That is something which no one has ever suggested before!

Oh, plenty of people have suggested tailconst, but it's generally
expected to be more along the lines of

    tailconst(C) c;



  This should of
  course deprecate the use of non-attribute const() form.


You can't! How could you declare

    const(int[][][])[][][] x;

without the brackets? (Not that I have a use for that particular type,
but hopefully you see the point).



 "tailconst S s;", which
  in my syntax is "const(S) s;"


If you stop calling it const(S), I'll stop arguing with you. :-). I'm
still on the fence as to its utility, and Walter still says he can't
implement it, but if people want it, and Walter turns out to be wrong,
I certainly won't complain.



  I see your main concern is educational.   This is resolved very simple,
  too: teach that /everything/ in D are objects, and everything is by
  reference.


Teaching lies is just plain wrong. D has both value type and reference types.
Feb 20 2008
parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Janice Caron <caron800 googlemail.com> wrote:

 Well then you really haven't understood it all. The characters of a
 string may be stored in a ROM segment, and for that reason, the
 characters of a string may not be modified.


Of course I understand that.


 But there is no reason why
 you can't modify slices which merely point into that ROM data.


Modifying a slice which points i-dont-know-where feels unsafe to me.  I 
won't use this feature as long as I can.


 Actually, const() syntax is already different from const attribute.


 
 Again, you're wrong. The following two lines
 
     const int x;
     const(int)x;
 
 are identical in meaning. And that remains true for any type, no
 matter how complicated, e.g.


I'm talking about syntax, not semantics. const is an attribute, const() 
is a function.  I believe that the language lexer was specifically 
modified to allow for this functional const notation.


  Probably if we had a tailconst attribute instead, so that it was
  possible to write

  tailconst
  {
         C c;
         int x;  // either illegal, or not affected
  }


 
 That is something which no one has ever suggested before!
 
 Oh, plenty of people have suggested tailconst, but it's generally
 expected to be more along the lines of
 
     tailconst(C) c;


This is strange.  tailconst attribute merges smoothly with the language 
design.  On the contrary, the functional attributes, const included, 
look strange.


  This should of
  course deprecate the use of non-attribute const() form.


 
 You can't! How could you declare
 
     const(int[][][])[][][] x;
 
 without the brackets? (Not that I have a use for that particular type,
 but hopefully you see the point).


This use of "partial const", in addition to "full const" and "tail 
const", is specific to multi-dimentional arrays.  No other types can 
make use of it.  With arrays, you probably can do with aliasing:

	alias const int[][][] constArr;
	constArr[][][] x;

-- 
SnakE
Feb 20 2008
parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 20/02/2008, Sergey Gromov <snake.scaly gmail.com> wrote:

 Modifying a slice which points i-dont-know-where feels unsafe to me.  I
  won't use this feature as long as I can.


    string s = "hello world";
    s = s[6..$];

In what way is this unsafe?


  > How could you declare
  >
  >     const(int[][][])[][][] x;
  >
  > without the brackets?

 This use of "partial const", in addition to "full const" and "tail
  const", is specific to multi-dimentional arrays.  No other types can
  make use of it.


Sure they can

    const(int***)*** x;

or, perhaps more usefully

    int[const(int)[]] map;

There are an infinity of possible examples.



  With arrays, you probably can do with aliasing:

         alias const int[][][] constArr;
         constArr[][][] x;


And this to you would be a good thing?
Feb 20 2008
parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Janice Caron <caron800 googlemail.com> wrote:

 On 20/02/2008, Sergey Gromov <snake.scaly gmail.com> wrote:

 Modifying a slice which points i-dont-know-where feels unsafe to me.  I
  won't use this feature as long as I can.


 
     string s = "hello world";
     s = s[6..$];
 
 In what way is this unsafe?


This is Ok.  It's changing the .length directly which I don't like, and 
which is actually unpredictable.


 

  > How could you declare
  >
  >     const(int[][][])[][][] x;
  >
  > without the brackets?

 This use of "partial const", in addition to "full const" and "tail
  const", is specific to multi-dimentional arrays.  No other types can
  make use of it.


 
 Sure they can
 
     const(int***)*** x;
 
 or, perhaps more usefully
 
     int[const(int)[]] map;
 
 There are an infinity of possible examples.


Ok I see.

Rounding up our discussion, all the argument was because I misunderstood 
the type system.  And, judging from this syntax is discussed often and 
even was supported in the compiler for some time, I'm not alone in my 
misunderstanding.  Seems like an educational problem.

-- 
SnakE
Feb 21 2008
parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 21/02/2008, Sergey Gromov <snake.scaly gmail.com> wrote:

 Janice Caron <caron800 googlemail.com> wrote:
 This is Ok.  It's changing the .length directly which I don't like, and
  which is actually unpredictable.


It's always safe, and it's always predictable. It's just not very useful.

    string s = "hello";
    s.length = 10;

s will now contain "hello" followed by five default-value chars. Given
that string contents are immutable, that's completely pointless. But
it makes a lot more sense with non-constant arrays. For example:

    char[] s;
    s.length = 5;
    /* blah */
    s.length = 25;
    /* blah */
    s.length = 10;

etc. In this case, the buffer will be reallocated somewhere else, and
the original contents copied so you don't lose anything. It's exactly
like calling realloc() in C or C++.
Feb 21 2008
parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Janice Caron wrote:

     char[] s;
     s.length = 5;
     /* blah */
     s.length = 25;
     /* blah */
     s.length = 10;
 
 etc. In this case, the buffer will be reallocated somewhere else, and
 the original contents copied so you don't lose anything. It's exactly
 like calling realloc() in C or C++.


Well, there's one difference between what happens there and realloc(); 
the latter deallocates the original while D leaves the original in place 
in case there are other references to it. (This is more workable in D 
than C/C++ though, since if there aren't the GC will clean it up)
Feb 21 2008
prev sibling next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Sergey Gromov wrote:

 Steven Schveighoffer <schveiguy yahoo.com> wrote:

 "Sergey Gromov" wrote

 Please, why invent new syntax ?

 const(T) t; // mutable ref to const T
 const{T t;} // const ref to const T, because of transitiviness

 This syntax even worked in one of the previous compiler versions!


 Yes, this is one of the trials of Walter to see if he could get tail-const 
 to work.

 The problem is if T is not a reference/pointer (such as int).  Now:

 const(T) t;
 T t;

 are equivalent, which is necessary to make that const system work.  To have 
 some variable declared as const(T), and then allow assignment to that 
 variable is completely inconsistent with the fundamental usage of 
 parentheses.  If you have something defined as f(x), the entirety of x 
 should be affected by f.  This is why that system was dropped, as it should 
 have been.


 
 If you create a generic algorithm which works with T, and declare 
 something as
 
 const(T) t;
 
 then you effectively assert that you're going to replace t with 
 different other Ts, but promise to keep integrity of a referenced T 
 intact, if anything is referenced at all.  This means that for int, 
 which is not referencing anything,
 
 const(int) t;
 
 is completely and safely equivalent to
 
 int t;
 
 without breaking any contracts of your algorithm.  Please provide an 
 example where "const(int) x;" absolutely must mean "const int x;" for a 
 generic algorithm to work properly.
 


I wasn't aware of tat syntax. Please retract all comments I made in this 
thread, this is exactly what I was looking for.
Feb 20 2008
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Robert Fraser" wrote

 Sergey Gromov wrote:

 Steven Schveighoffer wrote:

 "Sergey Gromov" wrote

 Please, why invent new syntax ?

 const(T) t; // mutable ref to const T
 const{T t;} // const ref to const T, because of transitiviness

 This syntax even worked in one of the previous compiler versions!


 Yes, this is one of the trials of Walter to see if he could get 
 tail-const to work.

 The problem is if T is not a reference/pointer (such as int).  Now:

 const(T) t;
 T t;

 are equivalent, which is necessary to make that const system work.  To 
 have some variable declared as const(T), and then allow assignment to 
 that variable is completely inconsistent with the fundamental usage of 
 parentheses.  If you have something defined as f(x), the entirety of x 
 should be affected by f.  This is why that system was dropped, as it 
 should have been.


 If you create a generic algorithm which works with T, and declare 
 something as

 const(T) t;

 then you effectively assert that you're going to replace t with different 
 other Ts, but promise to keep integrity of a referenced T intact, if 
 anything is referenced at all.  This means that for int, which is not 
 referencing anything,

 const(int) t;

 is completely and safely equivalent to

 int t;

 without breaking any contracts of your algorithm.  Please provide an 
 example where "const(int) x;" absolutely must mean "const int x;" for a 
 generic algorithm to work properly.


 I wasn't aware of tat syntax. Please retract all comments I made in this 
 thread, this is exactly what I was looking for.


Hm... maybe true, but this is not the supported syntax for the current or 
future compilers, so you will be stuck at D 2.004 or something (can't 
remember which one).  Don't retract those comments just yet ;)

-Steve
Feb 20 2008
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Sergey Gromov" wrote

 Steven Schveighoffer wrote:

 "Sergey Gromov" wrote

 Please, why invent new syntax ?

 const(T) t; // mutable ref to const T
 const{T t;} // const ref to const T, because of transitiviness

 This syntax even worked in one of the previous compiler versions!


 Yes, this is one of the trials of Walter to see if he could get 
 tail-const
 to work.

 The problem is if T is not a reference/pointer (such as int).  Now:

 const(T) t;
 T t;

 are equivalent, which is necessary to make that const system work.  To 
 have
 some variable declared as const(T), and then allow assignment to that
 variable is completely inconsistent with the fundamental usage of
 parentheses.  If you have something defined as f(x), the entirety of x
 should be affected by f.  This is why that system was dropped, as it 
 should
 have been.


 If you create a generic algorithm which works with T, and declare
 something as

 const(T) t;

 then you effectively assert that you're going to replace t with
 different other Ts, but promise to keep integrity of a referenced T
 intact, if anything is referenced at all.  This means that for int,
 which is not referencing anything,

 const(int) t;

 is completely and safely equivalent to

 int t;

 without breaking any contracts of your algorithm.  Please provide an
 example where "const(int) x;" absolutely must mean "const int x;" for a
 generic algorithm to work properly.


Sergey,  I am not arguing that the functionality that you wish to have is 
invalid.  In fact, I would have been ok with that syntax, and understood it 
once it was explained thoroughly.  But I have to say that I agree with 
Janice and Walter on this one, it was very confusing.

It just goes against the traditional usage of parentheses.  The idea is 
correct, the syntax is confusing.  Find another syntax.

-Steve
Feb 20 2008
parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Steven Schveighoffer <schveiguy yahoo.com> wrote:

 "Sergey Gromov" wrote

 If you create a generic algorithm which works with T, and declare
 something as

 const(T) t;

 then you effectively assert that you're going to replace t with
 different other Ts, but promise to keep integrity of a referenced T
 intact, if anything is referenced at all.  This means that for int,
 which is not referencing anything,

 const(int) t;

 is completely and safely equivalent to

 int t;

 without breaking any contracts of your algorithm.  Please provide an
 example where "const(int) x;" absolutely must mean "const int x;" for a
 generic algorithm to work properly.


 
 Sergey,  I am not arguing that the functionality that you wish to have is 
 invalid.  In fact, I would have been ok with that syntax, and understood it 
 once it was explained thoroughly.  But I have to say that I agree with 
 Janice and Walter on this one, it was very confusing.
 
 It just goes against the traditional usage of parentheses.  The idea is 
 correct, the syntax is confusing.  Find another syntax.


The traditional usage of parentheses is this: foo(x).  This means that a 
function foo is applied to its argument x, and not applied to everything 
else.  You are probably talking about some different tradition.  Please 
clarify.

-- 
SnakE
Feb 20 2008
next sibling parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 20/02/2008, Sergey Gromov <snake.scaly gmail.com> wrote:

 The traditional usage of parentheses is this: foo(x).  This means that a
  function foo is applied to its argument x, and not applied to everything
  else.  You are probably talking about some different tradition.  Please
  clarify.


Happy to.

It's the exact same tradition, except that the function in question is
called "const", not "foo". It takes a type as it's input (e.g int),
and yeilds a type as its output (in this case const int).
Feb 20 2008
parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Janice Caron <caron800 googlemail.com> wrote:

 On 20/02/2008, Sergey Gromov <snake.scaly gmail.com> wrote:

 The traditional usage of parentheses is this: foo(x).  This means that a
  function foo is applied to its argument x, and not applied to everything
  else.  You are probably talking about some different tradition.  Please
  clarify.


 
 Happy to.
 
 It's the exact same tradition, except that the function in question is
 called "const", not "foo". It takes a type as it's input (e.g int),
 and yeilds a type as its output (in this case const int).


I see, thank you.  It's really natural to think of const() as of a type-
yielding function, sort of typeof(), which never came to my mind for 
some reason.

But here is the caveat.

As I understand from your posts, you state that "const(C) x;", as well 
as "const C x;", declares a variable of type (const C).  But this is not 
true.  It actually declares a variable of type "const ref to const C".

Since declaration "C x;" declares x of type "ref to C", I seem to 
automatically assume that a declaration is actually

C ref x;

and therefore "const(C) x;" is actually "const(C) ref x;" which gives a 
variable x of type "ref to const C".  A C++ habit, I presume.  But it 
doesn't mean it's a bad approach.

-- 
SnakE
Feb 20 2008
parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 20/02/2008, Sergey Gromov <snake.scaly gmail.com> wrote:

  As I understand from your posts, you state that "const(C) x;", as well
  as "const C x;", declares a variable of type (const C).  But this is not
  true.  It actually declares a variable of type "const ref to const C".


No. Consider

    const(int) x;

This does not declare a variable of type "const ref to const int", it
declares a const int.

I understand that you're thinking of classes, but even with classes,
you're not quite getting what a class is. A class is /not/ the data on
the heap. (If that were so, it would be possible to create an array of
dereferenced class instances, and it isn't). No, a class /is the
reference/ - and indirectly, what that reference points to. Thus, a
const class /is/ a const reference.

A "tailconst" class, on the other hand, would be a class (by which I
mean, a reference) whose tail (the data on the heap) was const.
Feb 20 2008
parent reply Yigal Chripun <yigal100 gmail.com> writes:
what if we separate const into two keywords?
a) const would apply to data only. (transitively)
b) "bound" ( a new keyword ) would apply to references only  (transitively)

the idea is as follows:
Class c1 = new Class(); //all mutable
const Class c2 = new Class(); // mutable ref to const data
same as:
const(Class) c3 = new Class();
bound const Class c4 = new Class(); // bound (ie const) ref to const data
const int a; // a is const
bound int a; // illegal
bound Class c5 = new Class(); // const ref...
etc...
that's just a start of a start of an idea.
it could be developed much further... like where the "invariant" concept
would fit in with such a scheme.

-- Yigal

Janice Caron wrote:

 On 20/02/2008, Sergey Gromov <snake.scaly gmail.com> wrote:
   

  As I understand from your posts, you state that "const(C) x;", as well
  as "const C x;", declares a variable of type (const C).  But this is not
  true.  It actually declares a variable of type "const ref to const C".
     


 No. Consider

     const(int) x;

 This does not declare a variable of type "const ref to const int", it
 declares a const int.

 I understand that you're thinking of classes, but even with classes,
 you're not quite getting what a class is. A class is /not/ the data on
 the heap. (If that were so, it would be possible to create an array of
 dereferenced class instances, and it isn't). No, a class /is the
 reference/ - and indirectly, what that reference points to. Thus, a
 const class /is/ a const reference.

 A "tailconst" class, on the other hand, would be a class (by which I
 mean, a reference) whose tail (the data on the heap) was const.
Feb 20 2008
parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 20/02/2008, Yigal Chripun <yigal100 gmail.com> wrote:

  bound const Class c4 = new Class(); // bound (ie const) ref to const data


Wouldn't the word "const" be superfluous in that example, since
constancy is transitive? (If the reference is constant, the data
/must/ be).

It's an interesting idea, but I think, in general, if the compiler
sees an array like

    const(T)[] x;

then it has to mean that the array's contents are not modifiable. That
rule shouldn't depend on T, it should simply be true always. Ditto all
other collections.
Feb 20 2008
parent reply Yigal Chripun <yigal100 gmail.com> writes:
Janice Caron wrote:

 On 20/02/2008, Yigal Chripun <yigal100 gmail.com> wrote:
   

  bound const Class c4 = new Class(); // bound (ie const) ref to const data
     


 Wouldn't the word "const" be superfluous in that example, since
 constancy is transitive? (If the reference is constant, the data
 /must/ be).

 It's an interesting idea, but I think, in general, if the compiler
 sees an array like

     const(T)[] x;

 then it has to mean that the array's contents are not modifiable. That
 rule shouldn't depend on T, it should simply be true always. Ditto all
 other collections.
   


As I've already said: it's only a start of an idea and should be further
refined.
that said, you are right that it's superfluous in the example above.
I've mainly suggested a new keyword and the idea to seperate the two use
cases of const.
I'm not sure if the "bound" property should be transitive or not ( i
suggested that it is but all options should be explored..) and it all
depends on what semantics you want to achieve. maybe (probably) bound
should also imply const on the referred data and const would imply all
refs inside the data object to be bound.

another tweak that can be done: intead of an error, if you apply bound
to a value type (like a primitive) the compiler implicitly "casts" that
to a const, that way you example above of an array would work for any
type T. it could be used the same way in generic programming.

--Yigal
Feb 20 2008
parent reply Yigal Chripun <yigal100 gmail.com> writes:
Yigal Chripun wrote:

 Janice Caron wrote:
   

 On 20/02/2008, Yigal Chripun <yigal100 gmail.com> wrote:
   
     

  bound const Class c4 = new Class(); // bound (ie const) ref to const data
     
       


 Wouldn't the word "const" be superfluous in that example, since
 constancy is transitive? (If the reference is constant, the data
 /must/ be).

 It's an interesting idea, but I think, in general, if the compiler
 sees an array like

     const(T)[] x;

 then it has to mean that the array's contents are not modifiable. That
 rule shouldn't depend on T, it should simply be true always. Ditto all
 other collections.
   
     


 As I've already said: it's only a start of an idea and should be further
 refined.
 that said, you are right that it's superfluous in the example above.
 I've mainly suggested a new keyword and the idea to seperate the two use
 cases of const.
 I'm not sure if the "bound" property should be transitive or not ( i
 suggested that it is but all options should be explored..) and it all
 depends on what semantics you want to achieve. maybe (probably) bound
 should also imply const on the referred data and const would imply all
 refs inside the data object to be bound.

 another tweak that can be done: intead of an error, if you apply bound
 to a value type (like a primitive) the compiler implicitly "casts" that
 to a const, that way you example above of an array would work for any
 type T. it could be used the same way in generic programming.

 --Yigal
   


after thinking about the above here are my thoughts:
the problem is trying to apply a single rule to two very different
concepts, so either way you get some type of a compromise. so why not
just realize we have a duality in D and plan accordingly. thus instead
of the current rule which states:
for every type T, const(T) means that all of T is const and from it
derived the rule that const T = const(T)
and replace it with:
if T has value semantics (primitive, union, struct, enum, ..) than the
above rule applies.
else, T is a reference type (a class)  and const(T) means _only_ that
the instance data is const, and its reference is _not_.

what we get is that const(T)=const T only for value types.
now, instead of my proposed "bound" keyword, let's just use final which
is already a reserved keyword.
final will always imply const too because of const transitivity (it'll
be a superset of const). that way for value types the following are
identical:
const(S) s;
final S s;
final const S s; // could be reported by the compiler as redundant
const S s;
and for reference types (classes) we get the following behavior:
const(C) c = new C(); // mutable ref to const data
const C c = new C(); // same as above (compiler could issue a warning
for lack of parens)
final const(C) c = new C(); // const ref to const data
final const C c = new C(); //same as above
final C c = new C(); //same as above

no issues with const(int) being mutable and other unintuitive syntaxes.

generic programming - you can choose to use const(T)/const T for a
weaker input condition or a final T for a stronger input condition that
will enforce full constancy of T for all types.

for function definitions: 'in' should be mapped to const as defined
above, and as I suggested before the compiler should choose if he passes
the parameter by value or by reference with optional control of that by
the user (for system programming..)
also it could be worthwhile to make in the default.

D community - what do you think? am I totally wrong or is it a sane and
more powerful solution to const?

-- Yigal
Mar 06 2008
parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Thu, 06 Mar 2008 20:21:32 +0100, Yigal Chripun <yigal100 gmail.com>  =

wrote:


 Yigal Chripun wrote:

 Janice Caron wrote:


 On 20/02/2008, Yigal Chripun <yigal100 gmail.com> wrote:



  bound const Class c4 =3D new Class(); // bound (ie const) ref to c=








onst  =


 data


 Wouldn't the word "const" be superfluous in that example, since
 constancy is transitive? (If the reference is constant, the data
 /must/ be).

 It's an interesting idea, but I think, in general, if the compiler
 sees an array like

     const(T)[] x;

 then it has to mean that the array's contents are not modifiable. Th=






at

 rule shouldn't depend on T, it should simply be true always. Ditto a=






ll

 other collections.


 As I've already said: it's only a start of an idea and should be furt=




her

 refined.
 that said, you are right that it's superfluous in the example above.
 I've mainly suggested a new keyword and the idea to seperate the two =




use

 cases of const.
 I'm not sure if the "bound" property should be transitive or not ( i
 suggested that it is but all options should be explored..) and it all=





 depends on what semantics you want to achieve. maybe (probably) bound=





 should also imply const on the referred data and const would imply al=




l

 refs inside the data object to be bound.

 another tweak that can be done: intead of an error, if you apply boun=




d

 to a value type (like a primitive) the compiler implicitly "casts" th=




at

 to a const, that way you example above of an array would work for any=





 type T. it could be used the same way in generic programming.

 --Yigal


 after thinking about the above here are my thoughts:
 the problem is trying to apply a single rule to two very different
 concepts, so either way you get some type of a compromise. so why not
 just realize we have a duality in D and plan accordingly. thus instead=



 of the current rule which states:
 for every type T, const(T) means that all of T is const and from it
 derived the rule that const T =3D const(T)
 and replace it with:
 if T has value semantics (primitive, union, struct, enum, ..) than the=



 above rule applies.
 else, T is a reference type (a class)  and const(T) means _only_ that
 the instance data is const, and its reference is _not_.

 what we get is that const(T)=3Dconst T only for value types.
 now, instead of my proposed "bound" keyword, let's just use final whic=


h

 is already a reserved keyword.
 final will always imply const too because of const transitivity (it'll=



 be a superset of const). that way for value types the following are
 identical:
 const(S) s;
 final S s;
 final const S s; // could be reported by the compiler as redundant
 const S s;
 and for reference types (classes) we get the following behavior:
 const(C) c =3D new C(); // mutable ref to const data
 const C c =3D new C(); // same as above (compiler could issue a warnin=


g

 for lack of parens)
 final const(C) c =3D new C(); // const ref to const data
 final const C c =3D new C(); //same as above
 final C c =3D new C(); //same as above

 no issues with const(int) being mutable and other unintuitive syntaxes=


.

 generic programming - you can choose to use const(T)/const T for a
 weaker input condition or a final T for a stronger input condition tha=


t

 will enforce full constancy of T for all types.

 for function definitions: 'in' should be mapped to const as defined
 above, and as I suggested before the compiler should choose if he pass=


es

 the parameter by value or by reference with optional control of that b=


y

 the user (for system programming..)
 also it could be worthwhile to make in the default.

 D community - what do you think? am I totally wrong or is it a sane an=


d

 more powerful solution to const?

 -- Yigal


First problem I see is that it does not take into account D's two types =
of
const - const and invariant.

-- Simen
Mar 08 2008
parent reply Yigal Chripun <yigal100 gmail.com> writes:
Simen Kjaeraas wrote:

 On Thu, 06 Mar 2008 20:21:32 +0100, Yigal Chripun <yigal100 gmail.com>
 wrote:


 Yigal Chripun wrote:

 Janice Caron wrote:


 On 20/02/2008, Yigal Chripun <yigal100 gmail.com> wrote:



  bound const Class c4 = new Class(); // bound (ie const) ref to
 const data


 Wouldn't the word "const" be superfluous in that example, since
 constancy is transitive? (If the reference is constant, the data
 /must/ be).

 It's an interesting idea, but I think, in general, if the compiler
 sees an array like

     const(T)[] x;

 then it has to mean that the array's contents are not modifiable. That
 rule shouldn't depend on T, it should simply be true always. Ditto all
 other collections.


 As I've already said: it's only a start of an idea and should be
 further
 refined.
 that said, you are right that it's superfluous in the example above.
 I've mainly suggested a new keyword and the idea to seperate the two
 use
 cases of const.
 I'm not sure if the "bound" property should be transitive or not ( i
 suggested that it is but all options should be explored..) and it all
 depends on what semantics you want to achieve. maybe (probably) bound
 should also imply const on the referred data and const would imply all
 refs inside the data object to be bound.

 another tweak that can be done: intead of an error, if you apply bound
 to a value type (like a primitive) the compiler implicitly "casts" that
 to a const, that way you example above of an array would work for any
 type T. it could be used the same way in generic programming.

 --Yigal


 after thinking about the above here are my thoughts:
 the problem is trying to apply a single rule to two very different
 concepts, so either way you get some type of a compromise. so why not
 just realize we have a duality in D and plan accordingly. thus instead
 of the current rule which states:
 for every type T, const(T) means that all of T is const and from it
 derived the rule that const T = const(T)
 and replace it with:
 if T has value semantics (primitive, union, struct, enum, ..) than the
 above rule applies.
 else, T is a reference type (a class)  and const(T) means _only_ that
 the instance data is const, and its reference is _not_.

 what we get is that const(T)=const T only for value types.
 now, instead of my proposed "bound" keyword, let's just use final which
 is already a reserved keyword.
 final will always imply const too because of const transitivity (it'll
 be a superset of const). that way for value types the following are
 identical:
 const(S) s;
 final S s;
 final const S s; // could be reported by the compiler as redundant
 const S s;
 and for reference types (classes) we get the following behavior:
 const(C) c = new C(); // mutable ref to const data
 const C c = new C(); // same as above (compiler could issue a warning
 for lack of parens)
 final const(C) c = new C(); // const ref to const data
 final const C c = new C(); //same as above
 final C c = new C(); //same as above

 no issues with const(int) being mutable and other unintuitive syntaxes.

 generic programming - you can choose to use const(T)/const T for a
 weaker input condition or a final T for a stronger input condition that
 will enforce full constancy of T for all types.

 for function definitions: 'in' should be mapped to const as defined
 above, and as I suggested before the compiler should choose if he passes
 the parameter by value or by reference with optional control of that by
 the user (for system programming..)
 also it could be worthwhile to make in the default.

 D community - what do you think? am I totally wrong or is it a sane and
 more powerful solution to const?

 -- Yigal


 First problem I see is that it does not take into account D's two
 types of
 const - const and invariant.

 -- Simen


why not? I only used const to simplify. you can add variant with the
same rules.
let's say that final defaults to const, BUT, if you can also use:
---
final invariant(C)  c= new C(); // a const ref to invariant data
---
since both mutable and invariant implicitly cast to const, the above is
sufficient. invariant data will contain invariant pointers only but
they'll convert to const whenever necessary.
also perhaps it's worth considering to remove the const T syntax from
the language and always require parens. it will simplify usage and
remove confusion for C++ programmers, because now both the syntax and
the semantics are different so you can't confuse the meaning of const T.


-- Yigal
Mar 08 2008
parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 09/03/2008, Yigal Chripun <yigal100 gmail.com> wrote:

  also perhaps it's worth considering to remove the const T syntax from
  the language and always require parens.


The bad news is, that would also disallow

    const x = 3;

and

    const
    {
        int x = 3;
        int y = 4;
    }

The problem here is that "const" is an "attribute" in the grammar, and
therefore can be used anywhere "public", "static", "auto",
"version(X)", and so on can be used. Changing that would be a major
upheaval.

The simplest route to re-assignable const reference is probably a
template solution. In fact, if you look at the change log for D2.012,
you'll see that it says: "std.typecons: added undocumented Rebindable
in preparation for opImplicitCast." So, that sounds to me like as the
language permits (as soon as we have opImplicitCast) we'll also have
Rebindable!(T) - a rebindable class reference. We just need to hang on
a little bit longer.
Mar 08 2008
parent Yigal Chripun <yigal100 gmail.com> writes:
Janice Caron wrote:

 On 09/03/2008, Yigal Chripun <yigal100 gmail.com> wrote:
   

  also perhaps it's worth considering to remove the const T syntax from
  the language and always require parens.
     


 The bad news is, that would also disallow

     const x = 3;

 and

     const
     {
         int x = 3;
         int y = 4;
     }

 The problem here is that "const" is an "attribute" in the grammar, and
 therefore can be used anywhere "public", "static", "auto",
 "version(X)", and so on can be used. Changing that would be a major
 upheaval.

 The simplest route to re-assignable const reference is probably a
 template solution. In fact, if you look at the change log for D2.012,
 you'll see that it says: "std.typecons: added undocumented Rebindable
 in preparation for opImplicitCast." So, that sounds to me like as the
 language permits (as soon as we have opImplicitCast) we'll also have
 Rebindable!(T) - a rebindable class reference. We just need to hang on
 a little bit longer.
   


since all programming languages are Turing complete you can write code
to emulate what ever you want. With that line of thought you don't need
const as part of D either, as you can write template code to emulate
that feature. yet, it is in the D language. the point is, that while
Rebindable!(T) will solve the problem from an implementation point of
view, it still remains a hack IMHO that shows a lacking type system.
the fact that you can solve it with a template doesn't mean that it's a
better, cleaner design, and while taste is a personal thing, for me that
makes D look ugly and unpolished.
Walter's enum solution to the manifest constant is a similar issue,
while it does solve the problem, it remains IMHO an ugly hack.

all I wanted to point out is that i want a more elegant solution, and
that sometimes implementation driven design makes for bad decisions.
while manifest constants and enums probably should have the same
implementation (for example), that does not imply that the interface
should be the same too.
</rant>

--Yigal
Mar 09 2008
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Sergey Gromov" wrote

 Steven Schveighoffer wrote:

 "Sergey Gromov" wrote

 If you create a generic algorithm which works with T, and declare
 something as

 const(T) t;

 then you effectively assert that you're going to replace t with
 different other Ts, but promise to keep integrity of a referenced T
 intact, if anything is referenced at all.  This means that for int,
 which is not referencing anything,

 const(int) t;

 is completely and safely equivalent to

 int t;

 without breaking any contracts of your algorithm.  Please provide an
 example where "const(int) x;" absolutely must mean "const int x;" for a
 generic algorithm to work properly.


 Sergey,  I am not arguing that the functionality that you wish to have is
 invalid.  In fact, I would have been ok with that syntax, and understood 
 it
 once it was explained thoroughly.  But I have to say that I agree with
 Janice and Walter on this one, it was very confusing.

 It just goes against the traditional usage of parentheses.  The idea is
 correct, the syntax is confusing.  Find another syntax.


 The traditional usage of parentheses is this: foo(x).  This means that a
 function foo is applied to its argument x, and not applied to everything
 else.  You are probably talking about some different tradition.  Please
 clarify.


That is the usage I am referring to.  I'll spell it out in English:

class C means that C is equivalent to a "reference to a some data" that 
compromises the class that follows the given definition.

If I interpret const(C) as constant C, or substituting for the english 
definition of C, a constant reference to some data, it is natural to assume 
that both the data AND the reference are const.  It does not make intuitive 
sense that const(C) means reference to some constant data, where the const 
applies to the data, but not the reference, even though the reference is in 
C.  It makes even less sense that const(int) means mutable int.  X * means a 
pointer to X, so const(X) * means a pointer to a constant X, that makes 
sense.  But since classes do not have the reference separated in syntax, 
there is no way to bring that piece of it outside the parentheses.  This is 
why we need a new syntax, to make the definition clear and unambiguous.

Your intuition may vary from 99% of us here, but that doesn't really matter. 
Your solution isn't intuitive, it is confusing, it would hinder the adoption 
of D 2.  Walter is trying to attract as many coders as possible, not just 
you ;)

-Steve
Feb 20 2008
parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Steven Schveighoffer <schveiguy yahoo.com> wrote:

 The traditional usage of parentheses is this: foo(x).  This means that a
 function foo is applied to its argument x, and not applied to everything
 else.  You are probably talking about some different tradition.  Please
 clarify.


 
 That is the usage I am referring to.  I'll spell it out in English:
 
 class C means that C is equivalent to a "reference to a some data" that 
 compromises the class that follows the given definition.


At least, now I understand why we can't understand each other.

For a declaration,

C x;

you imply reference in C, and I imply reference in x.

const(C) x;   	// text written
const(C) (ref x);	// my understanding
const(C ref) x;	// your understanding

No wonder we can't agree.  Now I'm curious why the difference.  To me, C 
is a class, and x is a reference.  Why it's different for you ?

-- 
SnakE
Feb 20 2008
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Sergey Gromov" wrote

 Steven Schveighoffer wrote:

 The traditional usage of parentheses is this: foo(x).  This means that 
 a
 function foo is applied to its argument x, and not applied to 
 everything
 else.  You are probably talking about some different tradition.  Please
 clarify.


 That is the usage I am referring to.  I'll spell it out in English:

 class C means that C is equivalent to a "reference to a some data" that
 compromises the class that follows the given definition.




Arghh! I can't type today!  Compromises? :)


 At least, now I understand why we can't understand each other.

 For a declaration,

 C x;

 you imply reference in C, and I imply reference in x.

 const(C) x;   // text written
 const(C) (ref x); // my understanding
 const(C ref) x; // your understanding

 No wonder we can't agree.  Now I'm curious why the difference.  To me, C
 is a class, and x is a reference.  Why it's different for you ?


C is a class reference.  There is no way to express the type of the class 
data, because D doesn't support value-type classes.  I.e. there is no way to 
separate the reference from C.  Whenever you see:

class C {}

in D, It's like the equivalent in C++ of

class _C {};
typedef _C& C;

But in D there is no way to get at the type _C.  And D class references are 
rebindable.

In D, the type never is in the variable, it's always in the type 
declaration.

-Steve
Feb 20 2008