www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DMD 0.177 release

reply Walter Bright <newshound digitalmars.com> writes:
More ABI changes, and implicit [] => * no longer allowed.

http://www.digitalmars.com/d/changelog.html

http://ftp.digitalmars.com/dmd.175.zip
Dec 09 2006
next sibling parent "Rioshin an'Harthen" <rharth75 hotmail.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote:
 More ABI changes, and implicit [] => * no longer allowed.

 http://www.digitalmars.com/d/changelog.html

 http://ftp.digitalmars.com/dmd.175.zip

Awesome, just awesome... :)
Dec 09 2006
prev sibling next sibling parent "ideage" <lsina 126.com> writes:
Thank you , Walter! Great  D!





ideage. 
Dec 09 2006
prev sibling next sibling parent Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Walter Bright schrieb am 2006-12-09:
 More ABI changes, and implicit [] => * no longer allowed.

Thanks, runtime reflection seems to be within reach now. Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFFeqR3LK5blCcjpWoRAuZpAJ4mS+QO5idDF7tKA9nw5d8aZ0xipwCffTYp hFGtpTzRynIPfEhg4qJam48= =EAfw -----END PGP SIGNATURE-----
Dec 09 2006
prev sibling next sibling parent Kyle Furlong <kylefurlong gmail.com> writes:
Walter Bright wrote:
 More ABI changes, and implicit [] => * no longer allowed.
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.175.zip

Good release. http://www.digitalmars.com/d/type.html is broken at the moment.
Dec 09 2006
prev sibling next sibling parent reply Endea <notknown none.com> writes:
Walter Bright kirjoitti:
 More ABI changes, and implicit [] => * no longer allowed.
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.175.zip

/home/me/D/Derelict/lib/libDerelictGL.a(glx.o):(.gnu.linkonce.d.D47TypeInfo_S8derelict6opengl3glx15__GLXconte tRec6__initZ+0x14): undefined reference to `D8derelict6opengl3glx15__GLXcontextRec6__initZ' glx.d does not define the struct, only it's name: struct __GLXcontextRec; So back to .176 for a while...
Dec 09 2006
parent Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Endea schrieb am 2006-12-09:
 Walter Bright kirjoitti:
 More ABI changes, and implicit [] => * no longer allowed.
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.175.zip

/home/me/D/Derelict/lib/libDerelictGL.a(glx.o):(.gnu.linkonce.d.D47TypeInfo_S8derelict6opengl3glx15__GLXconte tRec6__initZ+0x14): undefined reference to `D8derelict6opengl3glx15__GLXcontextRec6__initZ' glx.d does not define the struct, only it's name: struct __GLXcontextRec; So back to .176 for a while...

The linux build of DMD seems to be a mix between version 0.176 and 0.177. Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFFesI+LK5blCcjpWoRAg+SAJsFITmQ0XjTOcSsDnxYaZIAICCgRgCfQvc5 kO1v0ikRMfz47MbJSw2P4lY= =Vbly -----END PGP SIGNATURE-----
Dec 09 2006
prev sibling next sibling parent nazo <lovesyao gmail.com> writes:
struct is value type so I don't like this change of cast and init.
I think that should introduce tuple literal as {} and support cast from 
tuple to struct like:

struct S{int x,y;}
S* s = &cast(S){0,0};//tuple literal + cast
*s = cast(S){0,0};//tuple literal + cast

#sorry for my poor English.
Dec 09 2006
prev sibling next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Walter Bright wrote:
 More ABI changes, and implicit [] => * no longer allowed.
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.175.zip

"# Casting a value v to a struct S is now rewritten as S(v). # Initializing a struct S from a value v is now rewritten as S(v)." It took me a moment to realise what you meant by this. This appears to be the latest answer to the multiple opCast problem, albeit only for when the target type is a struct. WIHYE could we please have at least an answer about this soon? http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.bugs&article_id=9360 Stewart.
Dec 09 2006
parent reply Boris Kolar <boris.kolar globera.com> writes:
== Quote from Stewart Gordon (smjg_1998 yahoo.com)'s article
 "# Casting a value v to a struct S is now rewritten as S(v).
 # Initializing a struct S from a value v is now rewritten as S(v)."
 It took me a moment to realise what you meant by this.

Can you please enlighten the rest of us too?
Dec 09 2006
parent Lars Ivar Igesund <larsivar igesund.net> writes:
Boris Kolar wrote:

 == Quote from Stewart Gordon (smjg_1998 yahoo.com)'s article
 "# Casting a value v to a struct S is now rewritten as S(v).
 # Initializing a struct S from a value v is now rewritten as S(v)."
 It took me a moment to realise what you meant by this.

Can you please enlighten the rest of us too?

S(v) ==> S.opCall(v), that is calling the static opCall of struct S with v as an argument. -- Lars Ivar Igesund blog at http://larsivi.net DSource & #D: larsivi
Dec 09 2006
prev sibling next sibling parent reply "JohnC" <johnch_atms hotmail.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:ele2k9$2hr5$1 digitaldaemon.com...
 More ABI changes, and implicit [] => * no longer allowed.

 http://www.digitalmars.com/d/changelog.html

 http://ftp.digitalmars.com/dmd.175.zip

opAssign is new as well, but it throws an AV - unless I'm not using it right? class Test { int value; void opAssign(int value) { this.value = value; } } void main() { Test t = 10; }
Dec 09 2006
next sibling parent "JohnC" <johnch_atms hotmail.com> writes:
"JohnC" <johnch_atms hotmail.com> wrote in message 
news:elef3s$30jn$1 digitaldaemon.com...
 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:ele2k9$2hr5$1 digitaldaemon.com...
 More ABI changes, and implicit [] => * no longer allowed.

 http://www.digitalmars.com/d/changelog.html

 http://ftp.digitalmars.com/dmd.175.zip

opAssign is new as well, but it throws an AV - unless I'm not using it right? class Test { int value; void opAssign(int value) { this.value = value; } } void main() { Test t = 10; }

Take that back. Actually, it does work: Test t = new Test; t = 10; Sadly it doesn't like a struct as the lvalue. There are no examples in the docs, so how it's supposed to be used is anyone's guess...
Dec 09 2006
prev sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
JohnC wrote:
  > opAssign is new as well, but it throws an AV - unless I'm not using it
 right?
 
 class Test {
 
   int value;
 
   void opAssign(int value) {
     this.value = value;
   }
 
 }
 
 void main() {
   Test t = 10;
 } 
 

This works: void main() { Test t = new Test; t = 10; } I'm surprised this overload is in, as I thought it was considered dangerous. Not that I'm complaining btw!
Dec 09 2006
prev sibling next sibling parent reply "Chris Miller" <chris dprogramming.com> writes:
Pretty cool stuff.

Suggestion:

Allow static opAssign to return an instance of the class that will be  =

assigned to the lvalue:
    class MyClass
    {
       this(int x) { }
       static MyClass opAssign(int x)
       {
          return new MyClass(x);
       }
    }
    // ...
    MyClass mc;
    mc =3D 3; // keeps mc null.

It seems logical to implement this proposal because to get the desired  =

effect right now you could do:
    mc =3D mc =3D 3;
Dec 09 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Chris Miller wrote:
 Allow static opAssign to return an instance of the class that will be 
 assigned to the lvalue:

This wasn't done because there are several use cases where you wouldn't want to erase all previous contents of the struct being assigned to.
Dec 09 2006
parent reply "Chris Miller" <chris dprogramming.com> writes:
On Sat, 09 Dec 2006 13:59:24 -0500, Walter Bright  
<newshound digitalmars.com> wrote:

 Chris Miller wrote:
 Allow static opAssign to return an instance of the class that will be  
 assigned to the lvalue:

This wasn't done because there are several use cases where you wouldn't want to erase all previous contents of the struct being assigned to.

But if it's optional it's up to the struct writer to use void as the return or not.
Dec 09 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Chris Miller wrote:
 On Sat, 09 Dec 2006 13:59:24 -0500, Walter Bright 
 <newshound digitalmars.com> wrote:
 
 Chris Miller wrote:
 Allow static opAssign to return an instance of the class that will be 
 assigned to the lvalue:

This wasn't done because there are several use cases where you wouldn't want to erase all previous contents of the struct being assigned to.

But if it's optional it's up to the struct writer to use void as the return or not.

I don't think that'll work. He'll wind up being forced to set all the fields.
Dec 09 2006
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Walter Bright wrote:
 Chris Miller wrote:
 On Sat, 09 Dec 2006 13:59:24 -0500, Walter Bright 
 <newshound digitalmars.com> wrote:
 
 Chris Miller wrote:
 Allow static opAssign to return an instance of the class that will 
 be assigned to the lvalue:

This wasn't done because there are several use cases where you wouldn't want to erase all previous contents of the struct being assigned to.

But if it's optional it's up to the struct writer to use void as the return or not.

I don't think that'll work. He'll wind up being forced to set all the fields.

Doesn't follow - there might not be any to set other than those that are an inherent part of the assignment operation. For example, consider an immutable big integer class. One might want Int x; ... x = 42; as syntactic sugar for x = new Int(42); Stewart.
Dec 11 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Stewart Gordon wrote:
 Walter Bright wrote:
 I don't think that'll work. He'll wind up being forced to set all the 
 fields.

an inherent part of the assignment operation.

But if there *are* other fields that shouldn't be set, a rule to preclude those cases would be a problem.
Dec 12 2006
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Walter Bright wrote:
 Stewart Gordon wrote:
 Walter Bright wrote:
 I don't think that'll work. He'll wind up being forced to set all the 
 fields.

an inherent part of the assignment operation.

But if there *are* other fields that shouldn't be set, a rule to preclude those cases would be a problem.

Exactly. *If* there are other fields that shouldn't be set. Do you even understand a word of what Chris is proposing? The programmer would have a choice - opAssign returning void to modify in-place the object referenced by the lvalue, or returning a new object that will be assigned to the lvalue. What is this precluding? Stewart.
Dec 13 2006
next sibling parent Sean Kelly <sean f4.ca> writes:
Stewart Gordon wrote:
 Walter Bright wrote:
 Stewart Gordon wrote:
 Walter Bright wrote:
 I don't think that'll work. He'll wind up being forced to set all 
 the fields.

an inherent part of the assignment operation.

But if there *are* other fields that shouldn't be set, a rule to preclude those cases would be a problem.

Exactly. *If* there are other fields that shouldn't be set. Do you even understand a word of what Chris is proposing? The programmer would have a choice - opAssign returning void to modify in-place the object referenced by the lvalue, or returning a new object that will be assigned to the lvalue. What is this precluding?

Just a few thoughts. If this change is implemented, it should apply to all assign ops, not just opAssign itself. So opAddAssign, opMulAssign, etc. Also, it seems like this could give rise to some interesting behavior: class MyClass { int val; this( int x ) { val = x; } MyClass opAssign( int x ) { return new MyClass( x ); } } void fn( MyClass c ) { c = 42; } MyClass c = new MyClass( 0 ); fn( c ); writefln( c.val ); Based on this suggestion, the above will print '0', not '42'. This is actually kind of an interesting situation, as it offers the possibility of making non-inout reference parameters immutable with respect to assign operations. The other consequence being that assign operations could change the address of a class reference as a side-effect, which may have an impact on optimization. It also may interact somewhat oddly with associative arrays and such, depending on how the compiler generates code. ie. MyClass[int] aa; aa[0] = new MyClass( 0 ); aa[0] = 42; writefln( aa[0].val ); What will the above print? This sort of behavior would need to be defined in the spec. Sean
Dec 13 2006
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Stewart Gordon wrote:
 Walter Bright wrote:
 Stewart Gordon wrote:
 Walter Bright wrote:
 I don't think that'll work. He'll wind up being forced to set all 
 the fields.

an inherent part of the assignment operation.

But if there *are* other fields that shouldn't be set, a rule to preclude those cases would be a problem.

Exactly. *If* there are other fields that shouldn't be set. Do you even understand a word of what Chris is proposing? The programmer would have a choice - opAssign returning void to modify in-place the object referenced by the lvalue, or returning a new object that will be assigned to the lvalue. What is this precluding?

opAssign has 3 externally visible characteristics: 1) the parameter 2) the 'this' pointer 3) the return value Your proposal mixes up 2 and 3. opAssign works like: a = b becomes: a.opAssign(b) The return value is not assigned to a, it is the value of the expression (a = b). Mixing up the return value and the assignment to a will cause problems, as the two are different things, and should be independent.
Dec 13 2006
next sibling parent reply "Andrei Alexandrescu (See Website for Email)" <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:
 opAssign has 3 externally visible characteristics:
 
 1) the parameter
 2) the 'this' pointer
 3) the return value
 
 Your proposal mixes up 2 and 3. opAssign works like:
 
     a = b
 becomes:
     a.opAssign(b)
 
 The return value is not assigned to a, it is the value of the expression 
 (a = b). Mixing up the return value and the assignment to a will cause 
 problems, as the two are different things, and should be independent.

That makes me wonder - if a = b is used without picking up its result (the usual case), and if opAssign() returns an S, will the compiler optimize away the extra copy at zero cost? What I think happens is that the function will take a pointer to the destination which is zero, so a comparison will be made. But perhaps the optimizer will take care of eliminating that? Andrei
Dec 13 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Andrei Alexandrescu (See Website for Email) wrote:
 That makes me wonder - if a = b is used without picking up its result 
 (the usual case), and if opAssign() returns an S, will the compiler 
 optimize away the extra copy at zero cost?

No. The caller and callee don't know about each other.
 What I think happens is that the function will take a pointer to the 
 destination which is zero, so a comparison will be made. But perhaps the 
 optimizer will take care of eliminating that?

You could have a null pointer passed to the return result, but that would entail an extra check on the part of the callee. This is why a lot of C++ code tends to return references instead of values.
Dec 13 2006
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:
 Andrei Alexandrescu (See Website for Email) wrote:
 
 That makes me wonder - if a = b is used without picking up its result 
 (the usual case), and if opAssign() returns an S, will the compiler 
 optimize away the extra copy at zero cost?

No. The caller and callee don't know about each other.
 What I think happens is that the function will take a pointer to the 
 destination which is zero, so a comparison will be made. But perhaps 
 the optimizer will take care of eliminating that?

You could have a null pointer passed to the return result, but that would entail an extra check on the part of the callee. This is why a lot of C++ code tends to return references instead of values.

I guess compiling internally two versions, one that returns S and one that returns void, might be worth looking into. Because right now user code for opAssign() can't be politically correct and efficient at the same time. Here's a better alternative: Require opAssign() to always return void and have the compiler return a reference to the left-hand side. That is, transform: a = b; into: (a.opAssign(b), a); with the mention that a only gets evaluated once. This way assignment _always_ returns its left-hand side and user code cannot subvert that behavior. Also the code will be efficient because no more spurious copies are being made. Andrei
Dec 13 2006
next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:
 I guess compiling internally two versions, one that returns S and one 
 that returns void, might be worth looking into. Because right now user 
 code for opAssign() can't be politically correct and efficient at the 
 same time.
 
 Here's a better alternative:
 
 Require opAssign() to always return void and have the compiler return a 
 reference to the left-hand side. That is, transform:
 
 a = b;
 
 into:
 
 (a.opAssign(b), a);
 
 with the mention that a only gets evaluated once.
 
 This way assignment _always_ returns its left-hand side and user code 
 cannot subvert that behavior. Also the code will be efficient because no 
 more spurious copies are being made.

It is possible to force the return type of opAssign. But I'd suggest making it an S*, with the rewrite to: *(a.opAssign(b))
Dec 14 2006
next sibling parent reply Lionello Lunesu <lio lunesu.remove.com> writes:
Walter Bright wrote:
 It is possible to force the return type of opAssign. But I'd suggest 
 making it an S*, with the rewrite to:
 
     *(a.opAssign(b))
 

class C { C* opAssign(...) {...} } struct S { S* opAssign(...) {...} } Seriously?? Ugh. Why not just "C opAssign" and "S opAssign"? In the opCall discussion you said yourself that the return value will be optimized. Am I missing something? L.
Dec 14 2006
next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Lionello Lunesu wrote:
 Walter Bright wrote:
 It is possible to force the return type of opAssign. But I'd suggest 
 making it an S*, with the rewrite to:

     *(a.opAssign(b))

class C { C* opAssign(...) {...} } struct S { S* opAssign(...) {...} } Seriously?? Ugh.

It isn't necessary for classes, as they are already reference types.
 Why not just "C opAssign" and "S opAssign"? In the opCall discussion you 
 said yourself that the return value will be optimized.
 
 Am I missing something?

Yes. The issue is that opAssign has both a return value *and* copies values into it's 'this' pointer.
Dec 14 2006
parent reply "Andrei Alexandrescu (See Website for Email)" <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:
 Why not just "C opAssign" and "S opAssign"? In the opCall discussion 
 you said yourself that the return value will be optimized.

 Am I missing something?

Yes. The issue is that opAssign has both a return value *and* copies values into it's 'this' pointer.

This is wrong. The assignment should return an lvalue, and the current semantics of opAssign do not allow that. Here is some code: void Increment(inout int x) { ++x; } int a; Increment(a = 5); This code leaves a containing the value 6. This is because a is first assigned a 5, then a is passed __as an lvalue__ to Increment, which bumps it. Now consider: struct S { int a; S opAssign(int x) { a = x; return this; } } void Increment(inout S x) { ++x.a; } S a; Increment(a = 5); This is going to have very different (and useless and unwanted) semantics. Again, the right thing to do: give the Caesar what belongs to the Caesar. Have the user do the assignment (and return void), and have the compiler pass the lhs lvalue around, when needed. Andrei
Dec 14 2006
parent reply Kevin Bealer <kevinbealer gmail.com> writes:
== Quote from Andrei Alexandrescu (See Website for Email) > Now consider:
 struct S {
    int a;
    S opAssign(int x) {
      a = x;
      return this;
    }
 }
 void Increment(inout S x) {
    ++x.a;
 }
 S a;
 Increment(a = 5);
 This is going to have very different (and useless and unwanted) semantics.
 Again, the right thing to do: give the Caesar what belongs to the
 Caesar. Have the user do the assignment (and return void), and have the
 compiler pass the lhs lvalue around, when needed.
 Andrei

This reminds me of the "opIndex" discussion we had here quite a while ago. The problem was that for user defined containers, you can't simulate X[i] if the contained type is something like a struct. class C { S s1; S opIndex(int i) { return s1; } } There is an opIndexAssign(), but it has the same problem when applied to the inout parameter. From the discussion at the time (Ben Hinkle might remember) I recall two possibilities that seemed to make sense to me. 1. Add a return type qualifier with "inout" semantics, like a C++ "&" type. Something like one of these, inout of course looks a bit funny: ref S opIndexRef(int i); inout S opIndexRef(int i); 2. Return S* and let the compiler apply the "*". S* opIndex(int i); Compiler silently transforms foo(x[i]) into foo(*x[i]) I think #2 is a lot like what has been suggested for opAssign(): A* A::opAssign(inout A b); S* A::opIndexAssign(int i); assign1: a.opAssign(b) -> (a.opAssign(b), a) assign2: a.opAssign(b) -> *(a.opAssign(b)) index1: a.opIndexAssign(i) -> *opIndexAssign(i) Where index1 is my opIndex suggestion (from way back) and assign1 and assign2 are Walter and Andrei's possible syntaxes for opAssign() respectively. Conceptually, the problem looks similar to me: how to "tunnel" an assignable type through a return value of a method, like the C++ "&" types do. The opIndex version needs to tunnel up through more layers than opAssign() does since it's not the A type, so the (a.opIndex(b), a) can't work there of course. I would vote for "S*" being the conceptual return type in both cases for opAssign() and opIndex(), although in the case of opAssign() it wouldn't bother me if the user visible signature was "void opAssign(...)" and the compiler handles the pointer as it does with this(). Kevin
Dec 14 2006
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Kevin Bealer wrote:
 This reminds me of the "opIndex" discussion we had here quite a while ago.  The
 problem was that for user defined containers, you can't simulate X[i] if the
 contained type is something like a struct.
 
 class C {
    S s1;
 
    S opIndex(int i)
    {
       return s1;
    }
 }
 
 There is an opIndexAssign(), but it has the same problem when applied to the
inout
 parameter.

Hm. This inability to return lvalues looks like a serious loophole within D's type system.
 1. Add a return type qualifier with "inout" semantics, like a C++ "&" type.
 
     Something like one of these, inout of course looks a bit funny:
 
     ref S opIndexRef(int i);
     inout S opIndexRef(int i);

This will have serious ripples through the type system. For example, people might start to ask themselves whether they can define standalone inout variables, and what that means. Or, tell inside a template whether it received an inout parameter or not. At any rate, Perl 5 has implemented this exact hack, and seems to be working with it. See: http://search.cpan.org/~nwclark/perl-5.8.7/pod/perlsub.pod#Lvalue_subroutines The Perl guys seem to be unhappy about it because they labeled it as "experimental" in Perl 5 and they discuss eliminating it in Perl 6, in favor of some even more exotic features. See: http://dev.perl.org/perl6/rfc/149.html
 2. Return S* and let the compiler apply the "*".
 
     S* opIndex(int i);
     Compiler silently transforms foo(x[i]) into foo(*x[i])

This is also (probably more) unsatisfactory. People will be able to index and obtain lvalues, but will be unable to return something assignable from a function: ++s[a]; // possible through a compiler hack ++s(a, b); // impossible
 Conceptually, the problem looks similar to me: how to "tunnel" an assignable
type
 through a return value of a method, like the C++ "&" types do.  The opIndex
 version needs to tunnel up through more layers than opAssign() does since it's
not
 the A type, so the (a.opIndex(b), a) can't work there of course.
 
 I would vote for "S*" being the conceptual return type in both cases for
 opAssign() and opIndex(), although in the case of opAssign() it wouldn't
bother me
 if the user visible signature was "void opAssign(...)" and the compiler handles
 the pointer as it does with this().

I see this as D's #1 major problem as of today. I think the function returning inout is better, but I foresee a bunch of issues with it. The question whether lvalues are needed beyond function return values must be satisfactorily answered. Andrei
Dec 14 2006
next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:
 I see this as D's #1 major problem as of today. I think the function
 returning inout is better, but I foresee a bunch of issues with it. The
 question whether lvalues are needed beyond function return values must
 be satisfactorily answered.

Ok, I think I understand the issue now. Also, it only applies to struct types, not class types. Class types are already reference types, so for them it's a non-issue.
Dec 14 2006
parent Kevin Bealer <kevinbealer gmail.com> writes:
== Quote from Walter Bright (newshound digitalmars.com)'s article
 Andrei Alexandrescu (See Website For Email) wrote:
 I see this as D's #1 major problem as of today. I think the function
 returning inout is better, but I foresee a bunch of issues with it. The
 question whether lvalues are needed beyond function return values must
 be satisfactorily answered.

Ok, I think I understand the issue now. Also, it only applies to struct types, not class types. Class types are already reference types, so for them it's a non-issue.

In the case of opIndex(), I think it does affect classes too. If I do this: void Swap(inout T a, inout T b) { T c=a; a=b; b=c; } class Vector { ... }; Vector X; 1. X[i].increment(); 2. Swap(X[i], X[j]); Both #1 and #2 would work for class or struct if X is a regular D array. For user-defined types, both of these fail if X is a struct. For classes, #1 works but I think #2 still fails. Kevin
Dec 15 2006
prev sibling parent reply Kevin Bealer <kevinbealer gmail.com> writes:
== Quote from Andrei Alexandrescu (See Website For Email)
(SeeWebsiteForEmail erdani.org)'s article
 Kevin Bealer wrote:

 2. Return S* and let the compiler apply the "*".

     S* opIndex(int i);
     Compiler silently transforms foo(x[i]) into foo(*x[i])

index and obtain lvalues, but will be unable to return something assignable from a function: ++s[a]; // possible through a compiler hack ++s(a, b); // impossible

I missed this possibility. In order to solve just this next step { ++s(a, b); }, it seems like D would need something that copies like a pointer to either a struct or class reference, but automatically turns into (or acts like) a regular reference or LValue when something like ++ is applied. This means something in between a pointer and an LValue. I'll keep calling it 'ref' for now. I think to get the semantics we'd expect it needs these properties: 1. For struct, it can be returned from a method/function or passed as an (inout) argument one or more times without causing any struct-copy to happen, and still referring to the original class reference (not just the original class). 2. For class, it can be used to modify the original object reference itself, i.e. for: ref C X::opIndex(int i); foo(inout C); foo(x[i]) should have the potential to modify the reference in the i'th location of x, by replacing with a different C object. 3. It should autoconvert to (or behave like) a regular LValue when something like ++ or += happens. Of course if += is called and opAddAssign() returns "ref T", then the returned reference would propagate a ref to the same original entity. 4. Due to #3, it cannot support things like pointer arithmetic (which is perfectly okay). Or assignment to the ref itself (the assign and other operations would by applied to the referred object of course). It's also probably convertable to a pointer via "&", i.e. address-of returns a pointer-to-original instead of pointer-to-ref. I guess this means it's impossible to get an address of the "ref" type itself except via trickery? I kind of hate to say it, but given all this, how far am I from describing a C++ "&" type? Is there anything the C++ type does that isn't in the above list? (Other than the new proposal for '& &' references I guess, which seems unnecessary for D.) Kevin
Dec 15 2006
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Kevin Bealer wrote:
 == Quote from Andrei Alexandrescu (See Website For Email)
 (SeeWebsiteForEmail erdani.org)'s article
 ++s[a]; // possible through a compiler hack
 ++s(a, b); // impossible

I missed this possibility. In order to solve just this next step { ++s(a, b); }, it seems like D would need something that copies like a pointer to either a struct or class reference, but automatically turns into (or acts like) a regular reference or LValue when something like ++ is applied. This means something in between a pointer and an LValue.

I think it's an lvalue all right. Inside the compiler it's very clear what's an lvalue and what's not. Think of this: int x; Wherever you use x, even if you pass it to functions etc., the compiler entirely knows it's an lvalue. If, on the other hand, you use (x + 1), all of a sudden the compiler understands that's an rvalue, and accordingly won't let you e.g. pass it as an out or inout parameter. I was quite worried last night about this issue, but now I think I realize that returning from a function is about the only (I hope!) case in which the lvalue yes/no information about a value is lost. That is, you can't today write a function ident() that is totally transparent - i.e., can be added around any expression with no effect whatsoever: template ident(T) { T ident(T rvalue) { // works return rvalue; } T ident(inout T lvalue) { // loss of information return lvalue; } } By the way, ident() is a good function to check a language's quality. If it can't be implemented at all or efficiently, then the language is not ideal. Most languages can implement ident() but not efficiently. C++ came close to implementing it properly, but all the confusion between rvalues and const references made implementation exceedingly difficult (to add insult to injury, built-in rvalues are treated differently than user-defined rvalues). Current D cannot implement ident at all. I also wonder whether overloading on inout is possible. I think not, and if not, that is a good urgent item to put on the list. The code that should compile and execute correctly is: template ident(T) { T ident(T rvalue) { // works return rvalue; } inout T ident(inout T lvalue) { // works return lvalue; } }
 I kind of hate to say it, but given all this, how far am I from describing a
C++
 "&" type?   Is there anything the C++ type does that isn't in the above list?
 (Other than the new proposal for '& &' references I guess, which seems
unnecessary
 for D.)

There are a few differences that make all the difference :o). One is that C++ is too eager to convert rvalues to const &, which has caused an unbounded amount of harm. Second, in C++, T& is a type indeed, but it's a half-life type, a pariah. So it would be probably wise to do the entire lvalue/rvalue distinction without making references into types. For example, outside function declarations, there should be no other place where inout can be used. Andrei
Dec 15 2006
next sibling parent Sean Kelly <sean f4.ca> writes:
Andrei Alexandrescu (See Website For Email) wrote:
 Kevin Bealer wrote:
 
 I kind of hate to say it, but given all this, how far am I from 
 describing a C++
 "&" type?   Is there anything the C++ type does that isn't in the 
 above list?
 (Other than the new proposal for '& &' references I guess, which seems 
 unnecessary
 for D.)

There are a few differences that make all the difference :o). One is that C++ is too eager to convert rvalues to const &, which has caused an unbounded amount of harm. Second, in C++, T& is a type indeed, but it's a half-life type, a pariah. So it would be probably wise to do the entire lvalue/rvalue distinction without making references into types. For example, outside function declarations, there should be no other place where inout can be used.

Agreed. In my time using D, the only time I've wished for a reference type is for function return values. The language doesn't need a general reference qualifier. Besides, we've already got inout parameter types, and it seems completely reasonable that one should be able to pass references out of a function as well as into a function. Sean
Dec 15 2006
prev sibling parent reply Kevin Bealer <kevinbealer gmail.com> writes:
== Quote from Andrei Alexandrescu (See Website For Email)
(SeeWebsiteForEmail erdani.org)'s article
 Kevin Bealer wrote:
 == Quote from Andrei Alexandrescu (See Website For Email)
 (SeeWebsiteForEmail erdani.org)'s article
 ++s[a]; // possible through a compiler hack
 ++s(a, b); // impossible

I missed this possibility. In order to solve just this next step { ++s(a, b); }, it seems like D would need something that copies like a pointer to either a struct or class reference, but automatically turns into (or acts like) a regular reference or LValue when something like ++ is applied. This means something in between a pointer and an LValue.

I think it's an lvalue all right. Inside the compiler it's very clear what's an lvalue and what's not. Think of this: int x; Wherever you use x, even if you pass it to functions etc., the compiler entirely knows it's an lvalue. If, on the other hand, you use (x + 1), all of a sudden the compiler understands that's an rvalue, and accordingly won't let you e.g. pass it as an out or inout parameter. I was quite worried last night about this issue, but now I think I realize that returning from a function is about the only (I hope!) case in which the lvalue yes/no information about a value is lost. That is, you can't today write a function ident() that is totally transparent - i.e., can be added around any expression with no effect whatsoever: template ident(T) { T ident(T rvalue) { // works return rvalue; } T ident(inout T lvalue) { // loss of information return lvalue; } } By the way, ident() is a good function to check a language's quality. If it can't be implemented at all or efficiently, then the language is not ideal. Most languages can implement ident() but not efficiently. C++ came close to implementing it properly, but all the confusion between rvalues and const references made implementation exceedingly difficult (to add insult to injury, built-in rvalues are treated differently than user-defined rvalues). Current D cannot implement ident at all. I also wonder whether overloading on inout is possible. I think not, and if not, that is a good urgent item to put on the list. The code that should compile and execute correctly is: template ident(T) { T ident(T rvalue) { // works return rvalue; } inout T ident(inout T lvalue) { // works return lvalue; } }
 I kind of hate to say it, but given all this, how far am I from describing a
C++
 "&" type?   Is there anything the C++ type does that isn't in the above list?
 (Other than the new proposal for '& &' references I guess, which seems
unnecessary
 for D.)

There are a few differences that make all the difference :o). One is that C++ is too eager to convert rvalues to const &, which has caused an unbounded amount of harm. Second, in C++, T& is a type indeed, but it's a half-life type, a pariah. So it would be probably wise to do the entire lvalue/rvalue distinction without making references into types. For example, outside function declarations, there should be no other place where inout can be used. Andrei

This is really interesting stuff. You've probably seen these already but lately D has gotten some compile time introspection stuff via tuples, in particular I'm thinking of (http://www.digitalmars.com/d/tuple.html) and (http://www.digitalmars.com/d/phobos/std_traits.html), which I think look quite useful. So I'm imagining a case of "meta-ident", which is to say, a template cousin of the ident test, applying the 'wrapper' concept to metaprogramming instead of programming. Knowing only the name of a method of a parameter class method (T::run), I want to duplicate it's signature in a template class method (A::meta). template A(T) { class A { T wrapped; this(T w) { wrapped = w; } ReturnType!(T.run) meta1(ParameterType!(T.run) i) { return wrapped.run(i); } inout ReturnType!(T.run) meta2(inout ParameterType!(T.run) i) { return wrapped.run(i); } } } Looking just at meta1, I'm wondering if it can absorbs the LValue-ness (inout qualification) through the Tuple. I'm thinking that it can't. If the LValue return type concept only affects function signatures as you say, then it can't be stored in a tuple, right? Instead it would get the type minus the inout qualifier? Now consider these two definitions of T::run(): struct S {...} S T::run1(in S x); inout S T::run2(inout S x); If I want to write a perfect-forwarding wrapper for run2, I need to use something like meta2, so that the LValue-ness is preserved. But meta2 can't work with run1, because the local S returned by run1 can't be returned via an inout return value. It would be returning a ref to a local var. So I need to know if the function takes and returns out vs. inout, in order to wrap it up like meta() is trying to do. This looks a bit like the C++ problem of having to define const and non-const versions of all the operators, except that meta1 or meta2 will do the wrong thing *silently* in these cases, either returning references to local vars (meta2 + run1), or discarding LValue-ness (meta1 + run2). Maybe I'm solving a non-problem here: in most cases the user should know if T::run() returns an LValue or RValue; for example, opIndex() could be understood to always return an LValue by convention. It seems like this local case could be solved by making ReturnType!() and ParameterTypeTuple!() into language attributes, so that they could see the fully qualified function-signature grade types with passing conventions etc. T::run.return_type_of meta_all(T::run.parameter_type_of[0..$] x) { // pass all the parameters via some kind of compiler-aware tuple return wrapped.run(x[0..$]); } Which could presumably, provide perfect forwarding of T::run() when used in a function signature context. [Or maybe there's always a conceptual 'leak' in these kinds of systems, and it can only be pushed a finite distance toward obscurity with each new language feature. I hope not, but...] Kevin
Dec 15 2006
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Kevin Bealer wrote:
 This is really interesting stuff.  You've probably seen these already but
lately D
 has gotten some compile time introspection stuff via tuples, in particular I'm
 thinking of (http://www.digitalmars.com/d/tuple.html) and
 (http://www.digitalmars.com/d/phobos/std_traits.html), which I think look quite
 useful.

I'm familiar with those :o).
 So I'm imagining a case of "meta-ident", which is to say, a template cousin of
the
 ident test, applying the 'wrapper' concept to metaprogramming instead of
 programming.  Knowing only the name of a method of a parameter class method
 (T::run), I want to duplicate it's signature in a template class method
(A::meta).

 Looking just at meta1, I'm wondering if it can absorbs the LValue-ness (inout
 qualification) through the Tuple.  I'm thinking that it can't.  If the LValue
 return type concept only affects function signatures as you say, then it can't
be
 stored in a tuple, right?  Instead it would get the type minus the inout
qualifier?

Your observation is correct. It all boils down to this: if "inout" is not part of the type system, there are two issues: (1) two overloads will always be needed to catch it (the similar way it's needed to overload the same function on const/non-const), and also (2) compile-time introspection would be more complicated as you need to "catch" the inout part of the parameter separately - the type won't be part of it.
 It seems like this local case could be solved by making ReturnType!() and
 ParameterTypeTuple!() into language attributes, so that they could see the
fully
 qualified function-signature grade types with passing conventions etc.
 
   T::run.return_type_of  meta_all(T::run.parameter_type_of[0..$] x)
   {
       // pass all the parameters via some kind of compiler-aware tuple
       return wrapped.run(x[0..$]);
   }
 
 Which could presumably, provide perfect forwarding of T::run() when used in a
 function signature context.
 
 [Or maybe there's always a conceptual 'leak' in these kinds of systems, and it
can
 only be pushed a finite distance toward obscurity with each new language
feature.
  I hope not, but...]

That remains to be seen, but I think the buck stops at functions. The problem of duplicating templates for inout (lvalues) and rvalues stays, but I have an idea about that, that I might tell about tomorrow. Andrei
Dec 15 2006
next sibling parent Georg Wrede <georg.wrede nospam.org> writes:
Andrei Alexandrescu (See Website For Email) wrote:
 Kevin Bealer wrote:
 
 This is really interesting stuff.  You've probably seen these already 
 but lately D has gotten some compile time introspection stuff 
 via tuples, in particular I'm thinking of 
 
 (http://www.digitalmars.com/d/tuple.html) and
 (http://www.digitalmars.com/d/phobos/std_traits.html), 

 which I think look quite useful.

I'm familiar with those :o).

LOL! Incidentally, the technical expertise, theoretical depth, and rigor of thinking that you've brought with you, have been sorely missed here. We'd be nowhere near this far without your already big contributions to D! I can hardly imagine what we've got ahead of us!
Dec 15 2006
prev sibling next sibling parent Kevin Bealer <kevinbealer gmail.com> writes:
== Quote from Andrei Alexandrescu (See Website For Email)
(SeeWebsiteForEmail erdani.org)'s article
 Kevin Bealer wrote:
 This is really interesting stuff.  You've probably seen these already but
lately D
 has gotten some compile time introspection stuff via tuples, in particular I'm
 thinking of (http://www.digitalmars.com/d/tuple.html) and
 (http://www.digitalmars.com/d/phobos/std_traits.html), which I think look quite
 useful.

I'm familiar with those :o).

Yes, I have this red covered book around here that goes into more depth, but I can never find it... :)
 So I'm imagining a case of "meta-ident", which is to say, a template cousin of
the
 ident test, applying the 'wrapper' concept to metaprogramming instead of
 programming.  Knowing only the name of a method of a parameter class method
 (T::run), I want to duplicate it's signature in a template class method
(A::meta).

 Looking just at meta1, I'm wondering if it can absorbs the LValue-ness (inout
 qualification) through the Tuple.  I'm thinking that it can't.  If the LValue
 return type concept only affects function signatures as you say, then it can't
be
 stored in a tuple, right?  Instead it would get the type minus the inout


 Your observation is correct. It all boils down to this: if "inout" is
 not part of the type system, there are two issues: (1) two overloads
 will always be needed to catch it (the similar way it's needed to
 overload the same function on const/non-const), and also (2)
 compile-time introspection would be more complicated as you need to
 "catch" the inout part of the parameter separately - the type won't be
 part of it.

 It seems like this local case could be solved by making ReturnType!() and
 ParameterTypeTuple!() into language attributes, so that they could see the
fully
 qualified function-signature grade types with passing conventions etc.

   T::run.return_type_of  meta_all(T::run.parameter_type_of[0..$] x)
   {
       // pass all the parameters via some kind of compiler-aware tuple
       return wrapped.run(x[0..$]);
   }

 Which could presumably, provide perfect forwarding of T::run() when used in a
 function signature context.

 [Or maybe there's always a conceptual 'leak' in these kinds of systems, and it
can
 only be pushed a finite distance toward obscurity with each new language
feature.
  I hope not, but...]

That remains to be seen, but I think the buck stops at functions. The problem of duplicating templates for inout (lvalues) and rvalues stays, but I have an idea about that, that I might tell about tomorrow. Andrei

That hint got me thinking and I had a look for myself at whether the current system can be used to make the distinction between in and inout. It took me a while to nail down a syntax that could do it. Of course, I can't test it with "inout" return types since we don't have those to play with, but I think what I have here might work for them if they were available. (Maybe inout is a bad name for a return type, but...) This is what I was able to make: import std.stdio; import std.traits; class Refer { alias int Item; Item run(inout Item x) { writefln("run(io)"); x += 300; return 10; } }; class Value { alias int Item; Item run(Item x) { writefln("run(i)"); x += 400; return 20; } }; template Baz(T) { class Baz { T wr_; this() { wr_ = new T(); } alias T.Item Item; alias Item delegate(inout Item) run_IO; alias Item delegate(Item) run_I; alias typeof(& (new T).run) TRunFunc; static if (is(typeof(TRunFunc) == typeof(run_IO))) { Item walk(inout Item x) { writefln("walk(io)"); x += 5000; return wr_.run(x); } } static if (is(typeof(TRunFunc) == typeof(run_I))) { Item walk(Item x) { writefln("walk(i)"); x += 6000; return wr_.run(x); } } } } int main(char[][] args) { alias Baz!(Value) TValue; alias Baz!(Refer) TRefer; TValue v = new TValue; TRefer r = new TRefer; int a = 0; int b = v.walk(a); int c = 0; int d = r.walk(c); writefln("\nValue semantics %s, %s.", a, b); writefln("Refer semantics %s, %s.", c, d); return 0; } Output looks like: walk(i) run(i) walk(io) run(io) Value semantics 0, 20. Refer semantics 5300, 10. So, I can match and select the preferred signature via delegates and typeof etc. Of course, if everyone uses this, it would be good to have some kind of shortcut for the above syntax. Maybe the IsExpression could be expanded to accept types like this: is(T.run() : int function(inout int)) Right now this is accepted (compiles) but does not seem to work - it always seems to evaluate as false. Kevin
Dec 16 2006
prev sibling parent reply Kevin Bealer <kevinbealer gmail.com> writes:
== Quote from Andrei Alexandrescu (See Website For Email)
...
 That remains to be seen, but I think the buck stops at functions. The
 problem of duplicating templates for inout (lvalues) and rvalues
 stays, but I have an idea about that, that I might tell about
 tomorrow.

 Andrei

Did you ever work out how to do this lvalue/rvalue idea? Kevin
Dec 19 2006
parent reply "Andrei Alexandrescu (See Website for Email)" <SeeWebsiteForEmail erdani.org> writes:
Kevin Bealer wrote:
 == Quote from Andrei Alexandrescu (See Website For Email)
 ...
 That remains to be seen, but I think the buck stops at functions. The
 problem of duplicating templates for inout (lvalues) and rvalues
 stays, but I have an idea about that, that I might tell about
 tomorrow.

 Andrei

Did you ever work out how to do this lvalue/rvalue idea?

I had to leave to Romania before having the time to post thoughts on the lvalue/rvalue discussion I've had with Walter on Saturday. We both agree that it's a serious problem with D's type system that needs fixing (and that he needs to do all the work :o)). I've continued to think of the issue, at least enough to figure that the solution we initially thought of is not sound. Walter is reluctant to offering the ability to overload on lvalue/rvalue, while it turns out that that can't be avoided. Let's return to my litmus test - the identity function ident(e), which can snuggle any expression e and leave its semantics unchanged. My thesis is that this function is an important test of a language's power. The starting point would be: template ident(T) { T ident(T e) { return e; } inout T ident(inout T e) { return e; } } The problem with this approach is that it doesn't scale. Right now "inout" is about the only interesting storage class of a function parameter, but "lazy" comes to mind (which I hope to get rid of soon via a much better solution) and later on we'll have "const", and each of these combinations will mean one more duplication of the ident body (and, by extension, of any function that wants to just pass the storage class outside). Walter had an idea along the line: template ident(T) { return T ident(return T e) { return e; } } which allows you to reuse the return keyword as a symbolic placeholder for passing out the storage class. This solution is severely shortsighted in that it fixes ident and only ident, whereas the purpose of ident is to serve as a simplified case for functions with multiple parameters. So this fell as well. We then discussed another solution that I won't bore you with, as it's so wrong it hurts. My current thoughts navigate around two possible solutions. One is to make the storage part of the template parameters: template ident(S T) { S T ident(S T e) { return e; } } When two adjacent symbols appear in a template parameter list, they unambiguously denote a storage class followed by a type. So "S" can bind to things like "in", "inout" etc., while "T" can bind to types. In the example above, the compiler will deduce both S and T from the argument type. It already does that, so that's no extra difficulty. The key point that makes this scale is that you can bind S and T multiple times in a variadic template. Another interesting detail is that it clarifies that you can't solve the problem without somehow compiling two versions of the ident function. So in the end overloading on "inout" is a must. Another solution that works is to commit to the idea of associating the storage class with the parameter (and divorce it from the type entirely). In that case, the following syntax describes what happens: template ident(T) { storageof(e) T ident(storageof(e) T e) { return e; } } The storageof(symbol) meta-operator yields the storage of that symbol. The problem with this notation is that it uses a symbol without having seen it. That's not too bad (it already happens due to the way symbols at global scope are looked up) but in this case it does have a fishy smell. Another thing that I don't like it that the code obscures what's going on - namely that one ident will be generated for each storage class, even though that's not reflected in the parameter type list. Finally, one related but slightly different topic is the necessity of deduced return types for functions, e.g. by using "auto" to denote the return type. Automatic deduction of return types is very useful in that it allows compact template function definition - no more need for a template that defines a homonym function. With deduced argument types, ident can be written as: auto ident(S T)(S T e) { return e; } which is, I think, the Platonic ideal of ident as far as expressing it in D goes. Andrei
Dec 20 2006
next sibling parent reply Lionello Lunesu <lio lunesu.remove.com> writes:
Andrei Alexandrescu (See Website for Email) wrote:
 Kevin Bealer wrote:
 == Quote from Andrei Alexandrescu (See Website For Email)
 ...
 That remains to be seen, but I think the buck stops at functions. The
 problem of duplicating templates for inout (lvalues) and rvalues
 stays, but I have an idea about that, that I might tell about
 tomorrow.

 Andrei

Did you ever work out how to do this lvalue/rvalue idea?


<snip> I'd like "auto" to appear on more places as it will make templates more accessible than ever before. For example, this notation has been suggested a couple of times: void func(auto x) { } I feel confident that having you and Walter on the issue, we should have a nice solution in no-time :) Sarbatori fericite! L. I'm actually leaving Romania to go to the Netherlands :)
Dec 20 2006
parent reply "Andrei Alexandrescu (See Website for Email)" <SeeWebsiteForEmail erdani.org> writes:
Lionello Lunesu wrote:
 Andrei Alexandrescu (See Website for Email) wrote:
 Kevin Bealer wrote:
 == Quote from Andrei Alexandrescu (See Website For Email)
 ...
 That remains to be seen, but I think the buck stops at functions. The
 problem of duplicating templates for inout (lvalues) and rvalues
 stays, but I have an idea about that, that I might tell about
 tomorrow.

 Andrei

Did you ever work out how to do this lvalue/rvalue idea?


<snip> I'd like "auto" to appear on more places as it will make templates more accessible than ever before. For example, this notation has been suggested a couple of times: void func(auto x) { }

Thanks for the kind wishes. One problem I see with the shortcut above is that the notation does not clarify whether "auto" catches both the type and the storage class. Even if it does, more linguistic machinery is needed to extract the type and storage class of x and to properly transport them, if needed, to the return type. So in the end the "auto" suggestion is a mere shortcut for: void func(S T)(S T x) { } with the difference that the storage and type entities are clearly bound to symbols, style that's more in the spirit of D. Andrei
Dec 20 2006
parent reply Reiner Pope <xxxxxx xxx.xx> writes:
Andrei Alexandrescu (See Website for Email) wrote:
 Lionello Lunesu wrote:
 Andrei Alexandrescu (See Website for Email) wrote:
 Kevin Bealer wrote:
 == Quote from Andrei Alexandrescu (See Website For Email)
 ...
 That remains to be seen, but I think the buck stops at functions. The
 problem of duplicating templates for inout (lvalues) and rvalues
 stays, but I have an idea about that, that I might tell about
 tomorrow.

 Andrei

Did you ever work out how to do this lvalue/rvalue idea?


<snip> I'd like "auto" to appear on more places as it will make templates more accessible than ever before. For example, this notation has been suggested a couple of times: void func(auto x) { }


 So in the end the "auto" suggestion is a mere shortcut for:
 
 void func(S T)(S T x) { }
 
 with the difference that the storage and type entities are clearly bound 
 to symbols, style that's more in the spirit of D.

The motivation I see for such a shortcut is that this template pattern is used so often that it is worth simplifying. Furthermore, the variables S and T are often just dummy variables to satisfy the requirements of the template; you don't even need these symbols, and they fill the namespace. Cheers, Reiner
Dec 20 2006
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Reiner Pope wrote:
 Andrei Alexandrescu (See Website for Email) wrote:
 Lionello Lunesu wrote:
 I'd like "auto" to appear on more places as it will make templates 
 more accessible than ever before. For example, this notation has been 
 suggested a couple of times:

 void func(auto x) { }


 So in the end the "auto" suggestion is a mere shortcut for:

 void func(S T)(S T x) { }

 with the difference that the storage and type entities are clearly 
 bound to symbols, style that's more in the spirit of D.

The motivation I see for such a shortcut is that this template pattern is used so often that it is worth simplifying. Furthermore, the variables S and T are often just dummy variables to satisfy the requirements of the template; you don't even need these symbols, and they fill the namespace.

I'm definitely one for shortcuts, but let's not forget that at the moment we lack the feature that the shortcut is supposed to simplify. At this moment, "auto" helps solving the storage class parameterization issue as much as a great color for the seat covers helps designing an economic automobile. Let me illustrate further why ident is important and what solution we should have for it. Consider C's response to ident: #define IDENT(e) (e) Now, you can use IDENT with many C expressions (except those that have top-level commas), so we should be glad. Or should we? A true solution is to intercept the type of the expression and intelligently pass it as the return type of the function. In the general case, that means the language offers total control to the programmer of the types tossed around by a program. Instead, the C solution cheats its way around in that it has absolutely no grip on the expression type; it just gives the illusion that a function call is going on. Similarly, let's say that a group of revolutionaries convinces Walter (as I understand happened in case of using "length" and "$" inside slice expressions, which is a shame and an absolute disaster that must be undone at all costs) to implement "auto", therefore leading to the following implementation of ident: auto ident(auto x) { return x; } In the euphoria of the celebration, it will be initially forgotten that we have the shortcut without the feature, for the feature means having access to the exact type and storage of x, not finding a way to comfortably specify a deduction process. Andrei
Dec 20 2006
next sibling parent reply Don Clugston <dac nospam.com.au> writes:
Andrei Alexandrescu (See Website For Email) wrote:
 Similarly, let's say that a group of revolutionaries convinces Walter 
 (as I understand happened in case of using "length" and "$" inside slice 
 expressions, which is a shame and an absolute disaster that must be 
 undone at all costs) to implement "auto"

This off-hand remark worries me. I presume that you mean being able to reference the length of a string, from inside the slice? (rather than simply the notation). And the problem being that it requires a sliceable entity to know its length? Or is the problem more serious than that? It's worrying because any change would break an enormous amount of code. These issues you're raising seem to be far too fundamental to be fixed in the next few days, casting grave doubts on whether a D1.0 release on Jan 1 is a good idea.
Dec 20 2006
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Don Clugston wrote:
 Andrei Alexandrescu (See Website For Email) wrote:
 Similarly, let's say that a group of revolutionaries convinces Walter 
 (as I understand happened in case of using "length" and "$" inside 
 slice expressions, which is a shame and an absolute disaster that must 
 be undone at all costs) to implement "auto"

This off-hand remark worries me. I presume that you mean being able to reference the length of a string, from inside the slice? (rather than simply the notation). And the problem being that it requires a sliceable entity to know its length? Or is the problem more serious than that? It's worrying because any change would break an enormous amount of code.

It would indeed break an enormous amount of code, but "all costs" includes "enormous costs". :o) A reasonable migration path is to deprecate them soon and make them illegal over the course of one year. A small book could be written on just how bad language design is using "length" and "$" to capture slice size inside a slice expression. I managed to write two lengthy emails to Walter about them, and just barely got started. Long story short, "length" introduces a keyword through the back door, effectively making any use of "length" anywhere unrecommended and highly fragile. Using "$" is a waste of symbolic real estate to serve a narrow purpose; the semantics isn't naturally generalized to its logical conclusion; and the choice of symbol itself as a reminiscent of Perl's regexp is at best dubious ("#" would have been vastly better as it has count connotation in natural language, and making it into an operator would have fixed the generalization issue). As things stand now, the rules governing the popping up of "length" and "$" constitute a sudden boo-boo on an otherwise carefully designed expression landscape.
 These issues you're raising seem to be far too fundamental to be fixed 
 in the next few days, casting grave doubts on whether a D1.0 release on 
 Jan 1 is a good idea.

The lvalue/rvalue issue is fundamental. I'm not in the position to assess whether it's a maker or breaker of D 1.0. The "length"/"$" issue is not fundamental the same way that C's declaration syntax, Java's throw specifications, C++'s use of "<" and ">" for templates, and Mao Zedong's refusal to use a toothbrush are not fundamental. It will "just" go down in history as a huge embarrassment and a good resource for cheap shooters and naysayers. If I understand its genesis, it will also be a canonical example of why design by committee is bad. Andrei
Dec 20 2006
next sibling parent Dave <Dave_member pathlink.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:
 Don Clugston wrote:
 Andrei Alexandrescu (See Website For Email) wrote:
 Similarly, let's say that a group of revolutionaries convinces Walter 
 (as I understand happened in case of using "length" and "$" inside 
 slice expressions, which is a shame and an absolute disaster that 
 must be undone at all costs) to implement "auto"

This off-hand remark worries me. I presume that you mean being able to reference the length of a string, from inside the slice? (rather than simply the notation). And the problem being that it requires a sliceable entity to know its length? Or is the problem more serious than that? It's worrying because any change would break an enormous amount of code.

It would indeed break an enormous amount of code, but "all costs" includes "enormous costs". :o) A reasonable migration path is to deprecate them soon and make them illegal over the course of one year. A small book could be written on just how bad language design is using "length" and "$" to capture slice size inside a slice expression. I managed to write two lengthy emails to Walter about them, and just barely got started. Long story short, "length" introduces a keyword through the back door, effectively making any use of "length" anywhere unrecommended and highly fragile. Using "$" is a waste of symbolic real estate to serve a narrow purpose; the semantics isn't naturally generalized to its logical conclusion; and the choice of symbol itself as a reminiscent of Perl's regexp is at best dubious ("#" would have been vastly better as it has count connotation in natural language, and making it into an operator would have fixed the generalization issue). As things stand now, the rules governing the popping up of "length" and "$" constitute a sudden boo-boo on an otherwise carefully designed expression landscape.

Are you suggesting either / both: slice = array[x .. array.length]; slice2 = array2[y .. #]; ? Since length and $ are pretty easily grep-able in the context of slice syntax, perhaps it's not a "huge" issue if these were deprecated now and then not supported in the span of a couple of 1.0.x releases or so (instead of a year)?
 These issues you're raising seem to be far too fundamental to be fixed 
 in the next few days, casting grave doubts on whether a D1.0 release 
 on Jan 1 is a good idea.

The lvalue/rvalue issue is fundamental. I'm not in the position to assess whether it's a maker or breaker of D 1.0.

Since one of the main drivers for 1.0 by Jan. 1, 2007 is to encourage / solidify library development, and since library design could be affected in a large way by this issue, I'd say it's best to figure this out before releasing 1.0.
 The "length"/"$" issue is not fundamental the same way that C's 
 declaration syntax, Java's throw specifications, C++'s use of "<" and 
 ">" for templates, and Mao Zedong's refusal to use a toothbrush are not 
 fundamental. It will "just" go down in history as a huge embarrassment 
 and a good resource for cheap shooters and naysayers. If I understand 
 its genesis, it will also be a canonical example of why design by 
 committee is bad.
 

If indeed it will be an embarrassment, better to take care of this sooner (pre-1.0) rather than later, IMHO. Thanks, - Dave
Dec 20 2006
prev sibling next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Wed, 20 Dec 2006 06:24:28 -0800, Andrei Alexandrescu (See Website For
Email) wrote:

 
 A small book could be written on just how bad language design is using 
 "length" and "$" to capture slice size inside a slice expression. I 
 managed to write two lengthy emails to Walter about them, and just 
 barely got started. 

Please share your thoughts here if you can too.
 Long story short, "length" introduces a keyword 
 through the back door, effectively making any use of "length" anywhere 
 unrecommended and highly fragile. 

There is no arguement from me on that score.
 Using "$" is a waste of symbolic real 
 estate to serve a narrow purpose;

By that do you mean that the symbol "$" could be better utilized elsewhere in the language?
 the semantics isn't naturally generalized to its logical conclusion;

I have no idea what that statement means. The semantics of *what*? Define "naturally generalized" in absolute terms without recourse to opinion. What is the "logical conclusion" you talk of?
 and the choice of symbol itself 
 as a reminiscent of Perl's regexp is at best dubious ("#" would have 
 been vastly better as it has count connotation in natural language

The concept was to have a very short symbol to represent the array's current element count. A number of different symbols were put forward, "#" being one of them. Walter rejected that one because it was already used for something else - the 'special token sequences' construct, such as "#line". Also symbols that consisted of identifier characters all have the same problem as "length" does. I favoured "$" because it was a single-character symbol and is already used in similar concepts inside regular expression syntaxes. Although the exact symbol that is 'finally' decided upon is not a burning issue for me, there would have to be a very solid argument for the provable superiority of that one symbol over the rest. And currently, the choice between "$" and "#" is equivalent in my mind.
 and making it into an operator would have fixed the generalization issue

Would this lead to an opLength() method available for overloading?
 As things stand now, the rules governing the popping up of "length" and 
 "$" constitute a sudden boo-boo on an otherwise carefully designed 
 expression landscape.

Still sounds like an opinion and not a fact, in my opinion ;-) -- Derek
Dec 20 2006
next sibling parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Derek Parnell wrote:
 The concept was to have a very short symbol to represent the array's
 current element count. A number of different symbols were put forward, "#"
 being one of them. Walter rejected that one because it was already used for
 something else - the 'special token sequences' construct, such as "#line".
 Also symbols that consisted of identifier characters all have the same
 problem as "length" does. I favoured "$" because it was a single-character
 symbol and is already used in similar concepts inside regular expression
 syntaxes.

The "[..$]" syntax is also present in ColdC and its relatives (including my Bovis), so it was familiar to me from the beginning. (That said I still harbor thoughts that $ could be used for other things... but honestly, I think the syntax would be unambiguous: a lone $ as the right hand side of a slice expression should easily enough be distinguishable from a $ anywhere followed by something, like an identifier.) Which leads me to another thought. One other operator that ColdC and family posesses is the for list splicing. Useless sample ColdC: # var foo, bar, result; # # foo = {1, 2, 3}; # bar = {4, 5, 6}; # result = { foo, bar}; The 'result' variable now equals {1, 2, 3, 4, 5, 6}. Perhaps we could get something similar in D, also using , and then I think would possibly be a logical choice for denoting "until end" in slices. I also think an 'opLength' operator is not a bad idea, but it might be best just to require a .length property of some kind be present, since presumably any class that exposes itself to slicing would likely also have a length concept of some kind. (Contrary examples welcome.) -- Chris Nicholson-Sauls
Dec 20 2006
parent reply BCS <BCS pathilink.com> writes:
Chris Nicholson-Sauls wrote:
 The "[..$]" syntax is also present in ColdC and its relatives (including 
 my Bovis), so it was familiar to me from the beginning.  (That said I 
 still harbor thoughts that $ could be used for other things... but 
 honestly, I think the syntax would be unambiguous: a lone $ as the right 
 hand side of a slice expression should easily enough be distinguishable 
 from a $ anywhere followed by something, like an identifier.)
 

FWIW $ is not only used for the RHS of a slice char[] str; str[$/2..$]; // 2nd half of array str[$-1]; // last element in array str[$-5..$]; // last 5 things in array str[$-10..10]; // um... well... you get the idea
 Which leads me to another thought.  One other operator that ColdC and 
 family posesses is the   for list splicing.  Useless sample ColdC:
 
 # var foo, bar, result;
 #
 # foo = {1, 2, 3};
 # bar = {4, 5, 6};
 # result = { foo,  bar};
 
 The 'result' variable now equals {1, 2, 3, 4, 5, 6}.

I would think this would be the same thing. auto foo = [1,2,3]; auto bar = [4,5,6]; auto result = foo ~ bar; am I missing somethign?
 
 -- Chris Nicholson-Sauls

Dec 20 2006
parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
BCS wrote:
 Chris Nicholson-Sauls wrote:
 The "[..$]" syntax is also present in ColdC and its relatives 
 (including my Bovis), so it was familiar to me from the beginning.  
 (That said I still harbor thoughts that $ could be used for other 
 things... but honestly, I think the syntax would be unambiguous: a 
 lone $ as the right hand side of a slice expression should easily 
 enough be distinguishable from a $ anywhere followed by something, 
 like an identifier.)

FWIW $ is not only used for the RHS of a slice char[] str; str[$/2..$]; // 2nd half of array str[$-1]; // last element in array str[$-5..$]; // last 5 things in array str[$-10..10]; // um... well... you get the idea

Ack. Having never used anything quite like that before, I guess I had assumed the $ only had meaning as I described above. Still, it could be possible.
 Which leads me to another thought.  One other operator that ColdC and 
 family posesses is the   for list splicing.  Useless sample ColdC:

 # var foo, bar, result;
 #
 # foo = {1, 2, 3};
 # bar = {4, 5, 6};
 # result = { foo,  bar};

 The 'result' variable now equals {1, 2, 3, 4, 5, 6}.

I would think this would be the same thing. auto foo = [1,2,3]; auto bar = [4,5,6]; auto result = foo ~ bar; am I missing somethign?

Not really, no. But consider: # ColdC D # # result = { foo, 0, bar}; result = foo ~ [0] ~ bar; # result = {42, someFunc()}; result = [42] ~ someFunc(); # result = { foo, 1, foo, 2}; result = foo ~ [1] ~ foo ~ [2]; # result = {3, 6, myConst, 9}; result = [3, 6] ~ myConst.dup ~ [9]; It becomes part of the literal syntax, which makes things cleaner in most elaborate cases. Just something I enjoy over there that I wouldn't mind seeing from time to time over here. :) -- Chris Nicholson-Sauls
Dec 20 2006
next sibling parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Chris Nicholson-Sauls wrote:
 BCS wrote:
 Chris Nicholson-Sauls wrote:
 The "[..$]" syntax is also present in ColdC and its relatives 
 (including my Bovis), so it was familiar to me from the beginning.  
 (That said I still harbor thoughts that $ could be used for other 
 things... but honestly, I think the syntax would be unambiguous: a 
 lone $ as the right hand side of a slice expression should easily 
 enough be distinguishable from a $ anywhere followed by something, 
 like an identifier.)

FWIW $ is not only used for the RHS of a slice char[] str; str[$/2..$]; // 2nd half of array str[$-1]; // last element in array str[$-5..$]; // last 5 things in array str[$-10..10]; // um... well... you get the idea

Ack. Having never used anything quite like that before, I guess I had assumed the $ only had meaning as I described above. Still, it could be possible.

These are very possible and are at times very useful. Though the last example is perhaps pushing it in the latter department ;). But yeah, $ is valid inside any [] pair, whether as (part of) an index or as (part of) either side of a slice.
 Which leads me to another thought.  One other operator that ColdC and 
 family posesses is the   for list splicing.  Useless sample ColdC:

 # var foo, bar, result;
 #
 # foo = {1, 2, 3};
 # bar = {4, 5, 6};
 # result = { foo,  bar};

 The 'result' variable now equals {1, 2, 3, 4, 5, 6}.

I would think this would be the same thing. auto foo = [1,2,3]; auto bar = [4,5,6]; auto result = foo ~ bar; am I missing somethign?

Not really, no. But consider: # ColdC D # # result = { foo, 0, bar}; result = foo ~ [0] ~ bar;

You don't need to surround a non-array by [] if concatenating with an array of the same type: result = foo ~ 0 ~ bar; will work just fine.
 # result = {42,  someFunc()};    result = [42] ~ someFunc();

result = 42 ~ someFunc();
 # result = { foo, 1,  foo, 2};   result = foo ~ [1] ~ foo ~ [2];

result = foo ~ 1 ~ foo ~ 2;
 # result = {3, 6,  myConst, 9};  result = [3, 6] ~ myConst.dup ~ [9];

result = [3, 6] ~ myConst ~ 9; The first []s are still needed, unless you add parentheses to group the 6 to myConst (and possibly the 9), but the last ones are unnecessary. Also, .dup is completely useless here (presuming myConst is an array) since ~ always allocates. (Note that repeated ~s in the same expression only allocate once though, at least in DMD)
Dec 20 2006
prev sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Chris Nicholson-Sauls wrote:
 BCS wrote:
 Chris Nicholson-Sauls wrote:

# ColdC D # # result = { foo, 0, bar}; result = foo ~ [0] ~ bar; # result = {42, someFunc()}; result = [42] ~ someFunc(); # result = { foo, 1, foo, 2}; result = foo ~ [1] ~ foo ~ [2]; # result = {3, 6, myConst, 9}; result = [3, 6] ~ myConst.dup ~ [9]; It becomes part of the literal syntax, which makes things cleaner in most elaborate cases. Just something I enjoy over there that I wouldn't mind seeing from time to time over here. :)

I think that syntax is a little more attractive than ~ for some cases. It makes it clearer that you're building a list. We don't say [] ~ 1 ~ 2 ~ 3 to make the array [1,2,3], after all. But for that reason (because it's generalizing array literals) I think it should use [] instead of {}. So result = [ foo, 0, bar]; To me that certainly does make it clearer that I'm making a list out of lists. The as a special symbol just for this kind of bothers me, though. And how would it work for user-defined types? I guess it could just be turned into the equivalent opCat calls... --bb
Dec 20 2006
prev sibling parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Derek Parnell wrote:
 On Wed, 20 Dec 2006 06:24:28 -0800, Andrei Alexandrescu (See Website For
 Email) wrote:
 
  
 A small book could be written on just how bad language design is using 
 "length" and "$" to capture slice size inside a slice expression. I 
 managed to write two lengthy emails to Walter about them, and just 
 barely got started. 

Please share your thoughts here if you can too.

Gladly; I dug my email and let me share a couple of excerpts. --------- int length = 5; int[] a = new int[length * 2]; int[] b = a[length .. length * 2]; int c = a[length - 1 .. (b[0 .. length])[0]); In each of its uses, length has a different semantics. The behavior is well-defined for all cases, but nonintuitive and about as pleasant as nails on the blackboard. Now D has a compile-time option to ban the "length" name in scopes in which the slice operator is used. That would render the example above illegal. There is also a rule that identifiers in nested scopes cannot mask one another. So length will be banned from *any* scope that nests a scope using a slice: int length; if (a) { foreach (b; c) { while (d) { switch (e) { case f: g = h[0 .. length - 1]; ... } } } } This code will not compile. Worse, it *will* compile until you add the slice operation. Combining the two rules and taking them to their logical conclusion, any code using "length" is frail because there's always a risk that somebody might insert a slice, rendering the entire function uncompilable. What happened is that now "length" has become a backdoor-introduced keyword. Books will advise users to never use it even when it works, coding standards will ban it, language lawyers will use it to detract D, and users of other languages will smile condescendingly and stay with their languages. There are a few ways out of it. "length" could be actually made a keyword. But even that one isn't very uniform, and steals yet another good identifier name. Another way out of it is to ban "length" but stick with "$". But "$" has another bunch of problems. It's a special character used only once, and only in a very particular situation. There is no general concept standing behind its usage: it sticks out like a sore thumb. "$" isn't the last index in an array. It's that only when used inside a slice, and refers only to the innermost index of the array. Quite a waste of a special character out there, and to little usefulness. But if we made "$" into an operator identifying the last element of _any_ array, which could refer to the last element of _the left-hand side_ array if we so want, then all of a sudden it becomes useful in a myriad of situations: int i = a[$ - 1]; // get last element int i = a[$b - 1]; // get a's element at position b.length - 1 if (a[$ - 1] == x) { ... } if ($a > 0) { ... } if ($a == $b) { ... } swap(a[0], a[$ - 1]); // swap first and last element --------------- Grammar for nullary/unary $: --------------- I think I nailed down the way the count operator $ can work in a manner that's terse, expressive, and safe. My basic goal is to enable the operator $ to be unary (applying to an array) to return its size, and also nullary (applying to nothing) to implicitly mean "fetch the size of the innermost array in the expression". So this code should work: int[] foo; foo[$ - 1]; // refers to foo's last element foo[$foo - 1]; // same int[][] bar; bar[foo[$]]; // refers to bar indexed with foo's last element bar[foo[$bar]]; // refers to bar indexed with foo's element at $bar To insert my operator $ within D's grammar, go to the grammar page: http://www.digitalmars.com/d/expression.html$UnaryExpression and scroll down to Unary Expression. There, add the following rules: UnaryExpression: PostfixExpression & UnaryExpression ... etc. etc. ... $ Identifier $ PostfixExpression . Identifier $ PostfixExpression ( ) $ PostfixExpression ( ArgumentList ) $ IndexExpression $ SliceExpression $ ArrayLiteral $ ( Expression ) Now a unary expression can be the $ operator followed by an identifier, a member access, a function call, an array access, or a slice expression (awesome! pick the size of the slice!), a literal array (for conformity), or a parenthesized expression. Perfect! But we haven't yet filled the role of $ as a nullary operator. To do so, let's go in the grammar to http://www.digitalmars.com/d/expression.html$PrimaryExpression and append one more rule to it the PrimaryExpression rule: PrimaryExpression: Identifier .Identifier ... etc. etc. ... $ Now the grammar is unambiguous and will properly distinguish unary and nullary uses of the $ operator. This is more elegant than the current crap with "$" and "length" popping up. Besides, you can now use $ in many more places than inside []s. However, the grammar size does increase quite a bit, which is more fuss than I hoped for just one operator. A simpler grammar would have been to simply allow: UnaryExpression: PostfixExpression & UnaryExpression ... etc. etc. ... $ PostfixExpression But this would have been ambiguous. If the compiler sees "$-1", then the bad grammar says that's a unary use of $ because -1 is a PostfixExpression. But that's not what we wanted! We wanted $ to be nullary. That's why I needed to put all the cases in UnaryExpression. Andrei
Dec 21 2006
next sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:
 Derek Parnell wrote:
 On Wed, 20 Dec 2006 06:24:28 -0800, Andrei Alexandrescu (See Website For
 Email) wrote:

  
 A small book could be written on just how bad language design is 
 using "length" and "$" to capture slice size inside a slice 
 expression. I managed to write two lengthy emails to Walter about 
 them, and just barely got started. 

Please share your thoughts here if you can too.

Gladly; I dug my email and let me share a couple of excerpts.

Wow, I understand it now. I only hope that at least 'length' will be deprecated before 1.0. I like your dollars. I'm not so good with grammars, will your proposal also work for user defined types?
Dec 21 2006
parent "Andrei Alexandrescu (See Website for Email)" <SeeWebsiteForEmail erdani.org> writes:
Lutger wrote:
 Wow, I understand it now. I only hope that at least 'length' will be 
 deprecated before 1.0.
 
 I like your dollars.

Well, just don't take'em away from my bank account :o).
 I'm not so good with grammars, will your proposal 
 also work for user defined types?

The plan is that $expression is rewritten into (expression).length. The consistent thing to do is to make that into an onXyz() function, but I don't find this name inconsistency jarring. Andrei
Dec 21 2006
prev sibling next sibling parent reply Pragma <ericanderton yahoo.removeme.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:
 
 A simpler grammar would have been to simply allow:
 
 UnaryExpression:
     PostfixExpression
     & UnaryExpression
     ... etc. etc. ...
     $ PostfixExpression
 
 But this would have been ambiguous. If the compiler sees "$-1", then the 
 bad grammar says that's a unary use of $ because -1 is a 
 PostfixExpression. But that's not what we wanted! We wanted $ to be 
 nullary. That's why I needed to put all the cases in UnaryExpression.
 

Nice post, and one heck of an argument! FWIW, I advocated something similar during the last round of debates before the '$' operator was introduced. What I wanted to see was '$' to become like 'this' within slice and array expressions, so that the issues regarding 'length' could be resolved. In essence one could simply say '$.length' and mean 'the length of the current array': b[0 .. $.length]; a[0 .. $.getIndexOf(';')]; So in essence, every use of '$' would be a 'nullary' operator - an alias if you will. I'd imagine that extending things in this manner would simplify things grammatically while allowing for a wider category of uses. However, it doesn't solve the issue that you brought up, and that I've quoted above. c[$-1]; It looks like it should be an implicit cast of the '$' to a size_t (length), via it's use in an expression. Any thoughts on this? -- - EricAnderton at yahoo
Dec 21 2006
next sibling parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Pragma wrote:
 Andrei Alexandrescu (See Website For Email) wrote:
 A simpler grammar would have been to simply allow:

 UnaryExpression:
     PostfixExpression
     & UnaryExpression
     ... etc. etc. ...
     $ PostfixExpression

 But this would have been ambiguous. If the compiler sees "$-1", then 
 the bad grammar says that's a unary use of $ because -1 is a 
 PostfixExpression. But that's not what we wanted! We wanted $ to be 
 nullary. That's why I needed to put all the cases in UnaryExpression.

Nice post, and one heck of an argument! FWIW, I advocated something similar during the last round of debates before the '$' operator was introduced. What I wanted to see was '$' to become like 'this' within slice and array expressions, so that the issues regarding 'length' could be resolved. In essence one could simply say '$.length' and mean 'the length of the current array': b[0 .. $.length]; a[0 .. $.getIndexOf(';')]; So in essence, every use of '$' would be a 'nullary' operator - an alias if you will.

I rather like this. And I think I liked it then, too... if not, oh well.
 I'd imagine that extending things in this manner would simplify things 
 grammatically while allowing for a wider category of uses.  However, it 
 doesn't solve the issue that you brought up, and that I've quoted above.
 
 c[$-1];
 
 It looks like it should be an implicit cast of the '$' to a size_t 
 (length), via it's use in an expression.  Any thoughts on this?

If $ is like a 'this', then it ought to be have semantically the same, so if $ is a class/struct with an opCast to size_t defined, the obvious happens. If its anything else, it ought to be a compile time error, perhaps suggesting you had meant '$.length' instead. -- Chris Nicholson-Sauls
Dec 21 2006
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Chris Nicholson-Sauls wrote:
 Pragma wrote:
 Andrei Alexandrescu (See Website For Email) wrote:
 A simpler grammar would have been to simply allow:

 UnaryExpression:
     PostfixExpression
     & UnaryExpression
     ... etc. etc. ...
     $ PostfixExpression

 But this would have been ambiguous. If the compiler sees "$-1", then 
 the bad grammar says that's a unary use of $ because -1 is a 
 PostfixExpression. But that's not what we wanted! We wanted $ to be 
 nullary. That's why I needed to put all the cases in UnaryExpression.

Nice post, and one heck of an argument! FWIW, I advocated something similar during the last round of debates before the '$' operator was introduced. What I wanted to see was '$' to become like 'this' within slice and array expressions, so that the issues regarding 'length' could be resolved. In essence one could simply say '$.length' and mean 'the length of the current array': b[0 .. $.length]; a[0 .. $.getIndexOf(';')]; So in essence, every use of '$' would be a 'nullary' operator - an alias if you will.


In both of those cases the use seems rather silly to me because a and b are both single characters to begin with. Might as well just type b[0 .. b.length]; a[0 .. a.getIndexOf(';')]; instead. But I get the point. Sometimes you have g_openSocketHandles[0 .. g_openSocketHandles.getIndexOf()] But maybe just allowing 'this' in the brackets is enough there, without going on and abbreviating it to $. The $==.length proposal at least has the advantage of being backwards compatible.

I rather like this. And I think I liked it then, too... if not, oh well.
 I'd imagine that extending things in this manner would simplify things 
 grammatically while allowing for a wider category of uses.  However, 
 it doesn't solve the issue that you brought up, and that I've quoted 
 above.

 c[$-1];

 It looks like it should be an implicit cast of the '$' to a size_t 
 (length), via it's use in an expression.  Any thoughts on this?

If $ is like a 'this', then it ought to be have semantically the same, so if $ is a class/struct with an opCast to size_t defined, the obvious happens. If its anything else, it ought to be a compile time error, perhaps suggesting you had meant '$.length' instead. -- Chris Nicholson-Sauls

Not sure I like $==this as must as $==.length. I have pressing need for a brief syntax for specifying the length, but no such thing for a shorter form of 'this'. But anyway, if you're going to allow '$' to mean 'this' inside brackets, first you first need the language feature that allows 'this' to be used inside brackets in the first place. And maybe if you have that you'll find it's sufficient. Another thing is if you're going to allow 'this' in brackets, then you should take the idea to its logical conclusions and allow it in member function call parameter lists too. That might be nice for things like enum paramters. Of course if $ gets translated into a call to a method/property, you could have it your way if you prefer for your classes. Just use opDollar() { return this; } and voila! You can use your $.getIndexOf(';'). --bb
Dec 21 2006
parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Bill Baxter wrote:
 Chris Nicholson-Sauls wrote:
 Pragma wrote:
 Andrei Alexandrescu (See Website For Email) wrote:
 A simpler grammar would have been to simply allow:

 UnaryExpression:
     PostfixExpression
     & UnaryExpression
     ... etc. etc. ...
     $ PostfixExpression

 But this would have been ambiguous. If the compiler sees "$-1", then 
 the bad grammar says that's a unary use of $ because -1 is a 
 PostfixExpression. But that's not what we wanted! We wanted $ to be 
 nullary. That's why I needed to put all the cases in UnaryExpression.

Nice post, and one heck of an argument! FWIW, I advocated something similar during the last round of debates before the '$' operator was introduced. What I wanted to see was '$' to become like 'this' within slice and array expressions, so that the issues regarding 'length' could be resolved. In essence one could simply say '$.length' and mean 'the length of the current array': b[0 .. $.length]; a[0 .. $.getIndexOf(';')]; So in essence, every use of '$' would be a 'nullary' operator - an alias if you will.


In both of those cases the use seems rather silly to me because a and b are both single characters to begin with. Might as well just type b[0 .. b.length]; a[0 .. a.getIndexOf(';')]; instead. But I get the point. Sometimes you have g_openSocketHandles[0 .. g_openSocketHandles.getIndexOf()] But maybe just allowing 'this' in the brackets is enough there, without going on and abbreviating it to $. The $==.length proposal at least has the advantage of being backwards compatible.

I rather like this. And I think I liked it then, too... if not, oh well.
 I'd imagine that extending things in this manner would simplify 
 things grammatically while allowing for a wider category of uses.  
 However, it doesn't solve the issue that you brought up, and that 
 I've quoted above.

 c[$-1];

 It looks like it should be an implicit cast of the '$' to a size_t 
 (length), via it's use in an expression.  Any thoughts on this?

If $ is like a 'this', then it ought to be have semantically the same, so if $ is a class/struct with an opCast to size_t defined, the obvious happens. If its anything else, it ought to be a compile time error, perhaps suggesting you had meant '$.length' instead. -- Chris Nicholson-Sauls

Not sure I like $==this as must as $==.length. I have pressing need for a brief syntax for specifying the length, but no such thing for a shorter form of 'this'. But anyway, if you're going to allow '$' to mean 'this' inside brackets, first you first need the language feature that allows 'this' to be used inside brackets in the first place. And maybe if you have that you'll find it's sufficient.

The problem with actually using the 'this' keyword in place of $ is one of ambiguity. Given a collection class 'Set' and some other class 'Foo', what to do if a 'this' is used within a slice of a 'Set' instance within a member of 'Foo'? Does it evaluate to the Foo referance it would in all other cases? Or to a Set referanc? And if the latter, how to get the Foo referance if that really is what I wanted? The $ would have to be different from 'this' in the classes' sense. Perhaps it would be better to call it a 'self' or even a 'with' than a 'this'. -- Chris Nicholson-Sauls
Dec 21 2006
prev sibling parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Pragma wrote:
 b[0 .. $.length];
 a[0 .. $.getIndexOf(';')];
 
 So in essence, every use of '$' would be a 'nullary' operator - an alias 
 if you will.

This isn't going to be agreeable to most since the purpose of $ in the first place was to save typing.
 I'd imagine that extending things in this manner would simplify things 
 grammatically while allowing for a wider category of uses.  However, it 
 doesn't solve the issue that you brought up, and that I've quoted above.
 
 c[$-1];
 
 It looks like it should be an implicit cast of the '$' to a size_t 
 (length), via it's use in an expression.  Any thoughts on this?

I'd rather have $ defined everywhere to mean length, which is useful outside [] as well. Andrei P.S. Maybe there's a misunderstanding? The grammar I sent does not have a problem w.r.t. unary vs. nullary; it's just a tad more complicated to avoid ambiguity.
Dec 22 2006
parent Pragma <ericanderton yahoo.removeme.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:
 Pragma wrote:
 b[0 .. $.length];
 a[0 .. $.getIndexOf(';')];

 So in essence, every use of '$' would be a 'nullary' operator - an 
 alias if you will.

This isn't going to be agreeable to most since the purpose of $ in the first place was to save typing.
 I'd imagine that extending things in this manner would simplify things 
 grammatically while allowing for a wider category of uses.  However, 
 it doesn't solve the issue that you brought up, and that I've quoted 
 above.

 c[$-1];

 It looks like it should be an implicit cast of the '$' to a size_t 
 (length), via it's use in an expression.  Any thoughts on this?

I'd rather have $ defined everywhere to mean length, which is useful outside [] as well.

Understood. I just figured I'd throw that out there in case it had any merit in the current discussion.
 
 Andrei
 
 P.S. Maybe there's a misunderstanding? The grammar I sent does not have 
 a problem w.r.t. unary vs. nullary; it's just a tad more complicated to 
 avoid ambiguity.

Ah, I understand then. The way you explained the grammar changes, it looked to me as though there was still an issue. -- - EricAnderton at yahoo
Dec 22 2006
prev sibling next sibling parent reply Don Clugston <dac nospam.com.au> writes:
Andrei Alexandrescu (See Website For Email) wrote:
 Another way out of it is to ban "length" but stick with "$". But "$" has 
 another bunch of problems. It's a special character used only once, and 
 only in a very particular situation. There is no general concept 
 standing behind its usage: it sticks out like a sore thumb. "$" isn't 
 the last index in an array. It's that only when used inside a slice, and 
 refers only to the innermost index of the array. Quite a waste of a 
 special character out there, and to little usefulness.
 
 But if we made "$" into an operator identifying the last element of 
 _any_ array, which could refer to the last element of _the left-hand 
 side_ array if we so want, then all of a sudden it becomes useful in a 
 myriad of situations:

Provided that some such expansion path for "$" exists, it would seem to be adequate for D 1.0 to just remove "length". And this could be done by Jan 1.
Dec 21 2006
parent "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Don Clugston wrote:
 Andrei Alexandrescu (See Website For Email) wrote:
 Another way out of it is to ban "length" but stick with "$". But "$" 
 has another bunch of problems. It's a special character used only 
 once, and only in a very particular situation. There is no general 
 concept standing behind its usage: it sticks out like a sore thumb. 
 "$" isn't the last index in an array. It's that only when used inside 
 a slice, and refers only to the innermost index of the array. Quite a 
 waste of a special character out there, and to little usefulness.

 But if we made "$" into an operator identifying the last element of 
 _any_ array, which could refer to the last element of _the left-hand 
 side_ array if we so want, then all of a sudden it becomes useful in a 
 myriad of situations:

Provided that some such expansion path for "$" exists, it would seem to be adequate for D 1.0 to just remove "length". And this could be done by Jan 1.

That is correct. One advantage of the unary/nullary $ is that it's a strict extension to today's $. Thus, no existing code will be invalidated by the new semantics of $. Andrei
Dec 22 2006
prev sibling next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:

 But if we made "$" into an operator identifying the last element of 
 _any_ array, which could refer to the last element of _the left-hand 
 side_ array if we so want, then all of a sudden it becomes useful in a 
 myriad of situations:
 
 int i = a[$ - 1]; // get last element
 int i = a[$b - 1]; // get a's element at position b.length - 1
 if (a[$ - 1] == x) { ... }
 if ($a > 0) { ... }
 if ($a == $b) { ... }
 swap(a[0], a[$ - 1]); // swap first and last element

Please give some thought to the case where a and b are of types not easily characterized by a single '.length'. Matrix classes, or more generally multidimensional array classes being the canonical examples. For those cases it is desirable to be able to have a '$' with different meaning "per axis". For those cases a we could have a small extension to your proposal. Have $b translate to b.length, yes, but also have $[3]b and $(1)b translate to to b.length[3] and b.length(1), respectively. Seeing that, it makes me think perhaps $ would be better as a post-fix unary operator. Then we'd have b$ --> b.length and b$[3] --> b.length[3]. Then of course the next step is to have a parameter number automatically passed to the length method given and expression like a[$-1,$-1] so that a[$-1,$-1] ==> a[$[0]-1,$[1]-1] ==> a[a$[0]-1,a$[1]-1] ==> a[a.length[0],a.length[1]] The compiler can decide whether to do indexing or not based on whether .length results in an indexable value. Finally, in general I think the choice of name 'length' is unfortunate because of it's implication of linearity. But it's not too late. If $ becomes associated with .size rather than .length in user types then everything will be ok. For built-in arrays .length can become a synonym for .size, just as it is with std::string in C++. C++/STL got this one right. For generic containers .size is a much better name. --bb
Dec 22 2006
next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Bill Baxter wrote:
 Andrei Alexandrescu (See Website For Email) wrote:
 

 Then of course the next step is to have a parameter number automatically 
 passed to the length method given and expression like a[$-1,$-1] so that
     a[$-1,$-1]
     ==>  a[$[0]-1,$[1]-1]
     ==>  a[a$[0]-1,a$[1]-1]
     ==>  a[a.length[0],a.length[1]]

Slight typo there. Last line should of course have been: ==> a[a.length[0]-1,a.length[1]-1]
 The compiler can decide whether to do indexing or not based on whether 
 .length results in an indexable value.
 
 Finally, in general I think the choice of name 'length' is unfortunate 
 because of it's implication of linearity.  But it's not too late.  If $ 
 becomes associated with .size rather than .length in user types then 
 everything will be ok.  For built-in arrays .length can become a synonym 
 for .size, just as it is with std::string in C++.  C++/STL got this one 
 right.  For generic containers .size is a much better name.

Another thing which occurred to me is that if the meaning of $ becomes tied to "size" rather than "length", then then you also have the mnemonic of $ looking like an 's' as in 'size'. I also still think making it a postfix operator makes sense. --bb
Dec 21 2006
prev sibling parent reply "Andrei Alexandrescu (See Website for Email)" <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:
 Andrei Alexandrescu (See Website For Email) wrote:
 
 But if we made "$" into an operator identifying the last element of 
 _any_ array, which could refer to the last element of _the left-hand 
 side_ array if we so want, then all of a sudden it becomes useful in a 
 myriad of situations:

 int i = a[$ - 1]; // get last element
 int i = a[$b - 1]; // get a's element at position b.length - 1
 if (a[$ - 1] == x) { ... }
 if ($a > 0) { ... }
 if ($a == $b) { ... }
 swap(a[0], a[$ - 1]); // swap first and last element

Please give some thought to the case where a and b are of types not easily characterized by a single '.length'. Matrix classes, or more generally multidimensional array classes being the canonical examples. For those cases it is desirable to be able to have a '$' with different meaning "per axis".

I did. The thing with language design is that it's easy to either underdo or overdo it, and that where underdoing or overdoing starts is highly subjective. IMHO the current meaning of "$" is a good example of underdoing. The "$expression" meaning "(expression).length" is (again IMHO) just right. I use collection.size() all the time in C++, and scalar( array) or $#array all the time in Perl, inside and outside index expressions. So I'd be happy to have that. Taking it to the next step of meaning any subdimension of a multidimensional (or fractal, heh) structure is, IMHO, overdoing because I can think of few use examples that are both frequent enough and interesting enough. Andrei
Dec 22 2006
parent Bill Baxter <wbaxter gmail.com> writes:
Andrei Alexandrescu (See Website for Email) wrote:
 Bill Baxter wrote:
 
 Andrei Alexandrescu (See Website For Email) wrote:

 But if we made "$" into an operator identifying the last element of 
 _any_ array, which could refer to the last element of _the left-hand 
 side_ array if we so want, then all of a sudden it becomes useful in 
 a myriad of situations:

 int i = a[$ - 1]; // get last element
 int i = a[$b - 1]; // get a's element at position b.length - 1
 if (a[$ - 1] == x) { ... }
 if ($a > 0) { ... }
 if ($a == $b) { ... }
 swap(a[0], a[$ - 1]); // swap first and last element

Please give some thought to the case where a and b are of types not easily characterized by a single '.length'. Matrix classes, or more generally multidimensional array classes being the canonical examples. For those cases it is desirable to be able to have a '$' with different meaning "per axis".

I did. The thing with language design is that it's easy to either underdo or overdo it, and that where underdoing or overdoing starts is highly subjective. IMHO the current meaning of "$" is a good example of underdoing. The "$expression" meaning "(expression).length" is (again IMHO) just right. I use collection.size() all the time in C++, and scalar( array) or $#array all the time in Perl, inside and outside index expressions. So I'd be happy to have that. Taking it to the next step of meaning any subdimension of a multidimensional (or fractal, heh) structure is, IMHO, overdoing because I can think of few use examples that are both frequent enough and interesting enough.

Maybe so. Multidimensional arrays seem as common as air from where I sit, but I can see that not everyone works with such things every day. If $ really did become synonymous with .length (or preferably .size) then one could have .length return an array rather than a simple number. In that case multi-dim'ers could have M[5..$[0]-1, 0..$[1]-5]. Eh. Not so pretty. For comparison, in Python that would be M[5:,:-5], and in Matlab that would be M(6:end, 1:end-4). Both of those look much better to me. If the index to go with $ could be supplied automatically by the compiler then D could have M[5..$-1, 0..$-5]. Taking a different tack, I wonder if repeated indexing can be made as efficient (or nearly) as a single multi-index? M[5..$-1][0..$-5] That's much easier to look at than M[5..$[0]-1, 0..$[1]-5], at least. And it's more general in the sense that from looking at the expression, M looks just like a standard Type[][] array. Hmm. I'll play with that. I think it's at least technically possible, now that D has the ability to override opAssign. --bb
Dec 22 2006
prev sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:
 A simpler grammar would have been to simply allow:
 
 UnaryExpression:
     PostfixExpression
     & UnaryExpression
     ... etc. etc. ...
     $ PostfixExpression
 
 But this would have been ambiguous. If the compiler sees "$-1", then the 
 bad grammar says that's a unary use of $ because -1 is a 
 PostfixExpression. But that's not what we wanted! We wanted $ to be 
 nullary. That's why I needed to put all the cases in UnaryExpression.

Wouldn't that ambiguity be fixed by making $ a postfix unary operator instead? Or would that just introduce different ambiguities? --bb
Dec 24 2006
prev sibling next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:
 Don Clugston wrote:
 Andrei Alexandrescu (See Website For Email) wrote:
 Similarly, let's say that a group of revolutionaries convinces Walter 
 (as I understand happened in case of using "length" and "$" inside 
 slice expressions, which is a shame and an absolute disaster that 
 must be undone at all costs) to implement "auto"

This off-hand remark worries me. I presume that you mean being able to reference the length of a string, from inside the slice? (rather than simply the notation). And the problem being that it requires a sliceable entity to know its length? Or is the problem more serious than that? It's worrying because any change would break an enormous amount of code.

It would indeed break an enormous amount of code, but "all costs" includes "enormous costs". :o) A reasonable migration path is to deprecate them soon and make them illegal over the course of one year. A small book could be written on just how bad language design is using "length" and "$" to capture slice size inside a slice expression. I managed to write two lengthy emails to Walter about them, and just barely got started. Long story short, "length" introduces a keyword through the back door, effectively making any use of "length" anywhere unrecommended and highly fragile.

That hadn't occurred to me, but you're right. I never use length in that context precisely because it does look like it could be a local identifier, whereas I know it'll be clear it's not if I use $. Also "length" is just too long to be of much use to me as a shortcut. If I'm going to be that verbose I might as well type out the whole "varname.length".
 Using "$" is a waste of symbolic real 
 estate to serve a narrow purpose; the semantics isn't naturally 
 generalized to its logical conclusion; 

I do use this one, but I agree. It is unnecessarily special cased for built-in array types. For user-defined types, in 'myvar[0..$]' the $ does not expand to 'myvar.length' as one would naturally expect it to. Or any sort of opLength() call. It's just a syntax error.
 and the choice of symbol itself 
 as a reminiscent of Perl's regexp is at best dubious ("#" would have 
 been vastly better as it has count connotation in natural language, and 
 making it into an operator would have fixed the generalization issue). 

I think you'll have to admit that's just your personal taste there. Using $ to indicate 'end' is a regexp thing, but regexp's go way beyond Perl. I don't really care what it is as long as there's an terse way to specify 'the end' in an indexing expression.
 As things stand now, the rules governing the popping up of "length" and 
 "$" constitute a sudden boo-boo on an otherwise carefully designed 
 expression landscape.

After trying to write a multi-dimensional array class, my opinion is that D slice support could use some upgrades overall. What I'd like to see: --MultiRange Slice-- * A way to have multiple ranges in a slice, and a mix slice of and non-slice indices: A[i..j, k..m] A[i..j, p, k..m] I'm not saying built-in arrays like int[] should allow the above expressions, but that at least user types should be allowed to have such opSlice methods. (Currently opSlice's are limited to having 2 arguments that represent the values that appear on either side of a single '..' token. You can only have two arguments max, but the arguments can be of any type.) The problem is that opSlice has to look like opSlice(T1 lo, T2 hi) right now -- just two parameters (or zero). One possible solution is to turn a single i..j into a single int[2] argument (or a mytype[2], for the general case). But that means one won't be able to distinguish A[[1,3]] from A[1..3]. It also means more interesting extensions to slice syntax, like adding a stepsize on a range, will be ruled out. Another solution is a built-in slice type. Ranges like a..b would get converted to slice instances automatically. It would basically be a struct with two ints in the simplest case, but to support user types as indexes it would need to be template-like, i.e. slice!(type). A slice would look basically like struct slice(T=int) { T lo,hi; } It could also have a .step property. With the above, lo and hi would have to be of the same type, but really it makes sense to let them differ, so slice!(T1,T2). For a range with stepsize, slice!(Tlo,Thi,Tstep). To make writing opSlice methods sane, a single number like the p above should be converted to a slice also. So all arguments passed to opSlice would be of type slice, and in the simple case of integer indices, it would just be: Type opSlice(slice s) { return x[s.lo..s.hi]; } since integers would be the default types for slice. --User Definable '$'-- * A way to specify 'the end' in user types. In the general case the meaning of '$' in a slice cannot be known (because any type can be used as an index), nor can it be simply substituted with something like a .length property, because it may depend on context. Consider a multi-dimensional array class -- A[0..$,3..$] The first $ means one thing, and the second one means another. One solution - make an opLength that gets called with the parameter number in which the $ appears. [My hypothesis is that the param# is the only context that ever matters in determining the meaning of $.] So in the above int opLength(int i) would get called twice, once with i==0, once with i==1. opLength can be made to return any type if the user just wants it to get 'passed through' to the opSlice call. If you don't need the context you can define it as opLength(). --Step sizes-- This is a handy feature of Python slices. The general syntax for a slice in Python is lo:hi:step, meaning go from 'lo' to 'hi', stepping by 'step' at a time. But any of the 3 components can be left out. lo:hi means step=1. lo::2 means go to the end, stepping by 2. :hi means 0 to hi. Negative steps are also allowed: hi:lo:-1 means go backwards from hi to lo ::-1 go backwards from the last to first element D syntax could be something like lo..hi:step. I like the omission part of Python's syntax. If D had that then most uses of $ would go away since we'd have A[3..] as an alternative to A[3..$]. --bb
Dec 20 2006
parent reply Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
Bill Baxter wrote:
 After trying to write a multi-dimensional array class, my opinion is 
 that D slice support could use some upgrades overall.

I'd be very interested in looking at what you've come up with. With my own implementation of a multi-dimensional array type a couple of months ago, I came to the same conclusion. I posted about it in: news://news.digitalmars.com:119/edrv0n$hth$1 digitaldaemon.com http://www.digitalmars.com/d/archives/digitalmars/D/announce/4717.html
 What I'd like to see:
 
 --MultiRange Slice--
 * A way to have multiple ranges in a slice, and a mix slice of and 
 non-slice indices:
     A[i..j, k..m]
     A[i..j, p, k..m]

      A[0..$,3..$]

Yes, I would too. It is quite frustrating having the syntax in the language but not being allowed to utilize it... :) I work around this by instead using a custom slice syntax instead: A[range(i,j), range(k,m)] A[range(i,j), p, range(k,m)] A[range(0,end), range(3..end)] A[end-1, p % end] Basicly, the transformation is: $ => end a..b => range(a,b) I briefly described this in: news://news.digitalmars.com:119/eft9id$2aq3$1 digitaldaemon.com The resulting code becomes quite optimal without the need for a position dependent opLength type of operator, but handling all the cases puts a larger burden on the implementor of opIndex.
 The problem is that opSlice has to look like opSlice(T1 lo, T2 hi) right 
 now -- just two parameters (or zero).

 Another solution is a built-in slice type.  Ranges like a..b would get 
 converted to slice instances automatically.  

Yes, this would be my suggestion too. Adding an opApply to one such built in range type would also have the nice side effect of allowing the syntactical sugar: foreach(i; 5..10)
 --User Definable '$'--

 One solution - make an opLength that gets called with the parameter 
 number in which the $ appears. 

Yes, that is probably the cleanest solution. And if no such opLength(int) overload exists, return the result of opLength() (or possibly .length) /Oskar
Dec 21 2006
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Oskar Linde wrote:
 Bill Baxter wrote:
 After trying to write a multi-dimensional array class, my opinion is 
 that D slice support could use some upgrades overall.

I'd be very interested in looking at what you've come up with. With my own implementation of a multi-dimensional array type a couple of months ago, I came to the same conclusion. I posted about it in: news://news.digitalmars.com:119/edrv0n$hth$1 digitaldaemon.com http://www.digitalmars.com/d/archives/digitalmars/D/announce/4717.html
 What I'd like to see:

 --MultiRange Slice--
 * A way to have multiple ranges in a slice, and a mix slice of and 
 non-slice indices:
     A[i..j, k..m]
     A[i..j, p, k..m]

> A[0..$,3..$] Yes, I would too. It is quite frustrating having the syntax in the language but not being allowed to utilize it... :) I work around this by instead using a custom slice syntax instead: A[range(i,j), range(k,m)] A[range(i,j), p, range(k,m)] A[range(0,end), range(3..end)] A[end-1, p % end]

Yeh, that's similar to what I'm doing too. But it's pretty ugly. So I guess that means you're using opIndex for everything and leaving opSlice alone. Are you able to have ranges return arrays and specific indexes return scalar values that way? That seems to me a big reason for having opSlice exist in the first place. The .. in the brackets not only means you're slicing, it also means the function should return another array, versus returning an element. That seems like a nice distinction to have to me.
 
 Basicly, the transformation is:
 
 $ => end
 a..b => range(a,b)
 
 I briefly described this in:
 news://news.digitalmars.com:119/eft9id$2aq3$1 digitaldaemon.com

Thanks for the link. The 'end' thing isn't so bad, at least for a former Matlab user. :-) --bb
Dec 24 2006
next sibling parent reply Reiner Pope <xxxxxx xxx.xx> writes:
Bill Baxter wrote:
 Oskar Linde wrote:
 Bill Baxter wrote:
 After trying to write a multi-dimensional array class, my opinion is 
 that D slice support could use some upgrades overall.

I'd be very interested in looking at what you've come up with. With my own implementation of a multi-dimensional array type a couple of months ago, I came to the same conclusion. I posted about it in: news://news.digitalmars.com:119/edrv0n$hth$1 digitaldaemon.com http://www.digitalmars.com/d/archives/digitalmars/D/announce/4717.html
 What I'd like to see:

 --MultiRange Slice--
 * A way to have multiple ranges in a slice, and a mix slice of and 
 non-slice indices:
     A[i..j, k..m]
     A[i..j, p, k..m]

> A[0..$,3..$] Yes, I would too. It is quite frustrating having the syntax in the language but not being allowed to utilize it... :) I work around this by instead using a custom slice syntax instead: A[range(i,j), range(k,m)] A[range(i,j), p, range(k,m)] A[range(0,end), range(3..end)] A[end-1, p % end]

Yeh, that's similar to what I'm doing too. But it's pretty ugly. So I guess that means you're using opIndex for everything and leaving opSlice alone. Are you able to have ranges return arrays and specific indexes return scalar values that way? That seems to me a big reason for having opSlice exist in the first place. The .. in the brackets not only means you're slicing, it also means the function should return another array, versus returning an element. That seems like a nice distinction to have to me.

syntactical sugar for foo[a..b][c][d..$] ? That way, I would imagine you could implement slicing and indexing of multidimensional arrays quite easily because, as Norbert Nemec said, indexing just returns an array with dimension reduced by one, and slicing returns an array of the same dimension, but perhaps different size. It also seems to allow any combination of slicing and indexing without needing variadic functions.
Dec 24 2006
next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Reiner Pope wrote:
 Bill Baxter wrote:
 Oskar Linde wrote:
 Bill Baxter wrote:
 After trying to write a multi-dimensional array class, my opinion is 
 that D slice support could use some upgrades overall.

I'd be very interested in looking at what you've come up with. With my own implementation of a multi-dimensional array type a couple of months ago, I came to the same conclusion. I posted about it in: news://news.digitalmars.com:119/edrv0n$hth$1 digitaldaemon.com http://www.digitalmars.com/d/archives/digitalmars/D/announce/4717.html
 What I'd like to see:

 --MultiRange Slice--
 * A way to have multiple ranges in a slice, and a mix slice of and 
 non-slice indices:
     A[i..j, k..m]
     A[i..j, p, k..m]

> A[0..$,3..$] Yes, I would too. It is quite frustrating having the syntax in the language but not being allowed to utilize it... :) I work around this by instead using a custom slice syntax instead: A[range(i,j), range(k,m)] A[range(i,j), p, range(k,m)] A[range(0,end), range(3..end)] A[end-1, p % end]

Yeh, that's similar to what I'm doing too. But it's pretty ugly. So I guess that means you're using opIndex for everything and leaving opSlice alone. Are you able to have ranges return arrays and specific indexes return scalar values that way? That seems to me a big reason for having opSlice exist in the first place. The .. in the brackets not only means you're slicing, it also means the function should return another array, versus returning an element. That seems like a nice distinction to have to me.

syntactical sugar for foo[a..b][c][d..$] ? That way, I would imagine you could implement slicing and indexing of multidimensional arrays quite easily because, as Norbert Nemec said, indexing just returns an array with dimension reduced by one, and slicing returns an array of the same dimension, but perhaps different size. It also seems to allow any combination of slicing and indexing without needing variadic functions.

Generally speaking, indexing isn't free. And doing it three times is 3x more expensive than doing it once. At the very least if the thing being indexed is a class then a new instance of that class has to be created for each index op. But likely there's also some internal state that has to be copied and adjusted as well. And one expects that indexing operations will often appear in inner loops, so they should be as fast as possible. However, if you use some sort of proxy structs to represent the intermediate indexing expressions and only do the indexing when it's really needed, it may be ok to use [][][]. Basically it's expression templates all over again, just here the expressions are limited to indexing or slice operations. That may work, and it may even be as efficient as a real multi-index slice with compiler optimizations, but I think it will result in code that's far less clear and probably not as fast. If it does pan out, though, then there are certainly advantages as you say to only having to worry about two cases ever -- single index and slice index. Not the any-possible-combination-of-index-and-slice, which admittedly requires some slick vararg template trickery itself. Anyway, I plan to try implementing that soon (with all the brackets, naturally since the syntactic sugar you mention currently doesn't exist). --bb
Dec 24 2006
prev sibling parent Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
== Quote from Reiner Pope (xxxxxx xxx.xx)'s article
 Is there anything particularly wrong with having foo[a..b,c,d..$] being
 syntactical sugar for foo[a..b][c][d..$] ? That way, I would imagine you
 could implement slicing and indexing of multidimensional arrays quite
 easily because, as Norbert Nemec said, indexing just returns an array
 with dimension reduced by one, and slicing returns an array of the same
 dimension, but perhaps different size. It also seems to allow any
 combination of slicing and indexing without needing variadic functions.

It is a neat idea that unfortunately doesn't work. foo[a..b,c..d] means slice from a to b along dimension 1 and from c to d along dimension 2. foo[a..b] would therefore return a 2-dimensional slice (same dimensionality as foo), and (foo[a..b])[c..d] would slice the same dimension again. Unless, of course, foo[a..b] would return some kind of proxy object that kept track of the last sliced dimension. /Oskar
Dec 26 2006
prev sibling parent reply Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
== Quote from Bill Baxter (dnewsgroup billbaxter.com)'s article
 Oskar Linde wrote:
 Bill Baxter wrote:
 After trying to write a multi-dimensional array class, my opinion is
 that D slice support could use some upgrades overall.

I'd be very interested in looking at what you've come up with. With my own implementation of a multi-dimensional array type a couple of months ago, I came to the same conclusion. I posted about it in: news://news.digitalmars.com:119/edrv0n$hth$1 digitaldaemon.com http://www.digitalmars.com/d/archives/digitalmars/D/announce/4717.html
 What I'd like to see:

 * A way to have multiple ranges in a slice, and a mix slice of and
 non-slice indices:
     A[i..j, k..m]
     A[i..j, p, k..m]

     A[0..$,3..$]

Yes, I would too. It is quite frustrating having the syntax in the language but not being allowed to utilize it... :) I work around this by instead using a custom slice syntax instead: A[range(i,j), range(k,m)] A[range(i,j), p, range(k,m)] A[range(0,end), range(3..end)] A[end-1, p % end]

guess that means you're using opIndex for everything and leaving opSlice alone.

Yes. Apart from the no-argument opSlice and opSliceAssign, that I overload with the same meaning as for the built in arrays. opSlice is not designed to support more than one dimension.
 Are you able to have ranges return arrays and specific indexes
 return scalar values that way?

Yes.
 That seems to me a big reason for having
 opSlice exist in the first place.  The .. in the brackets not only means
 you're slicing, it also means the function should return another array,
 versus returning an element.  That seems like a nice distinction to have
 to me.

Yes, definitely. My implementation mimics the behavior of the D native array/slice type (T[]), but extended for multiple dimensions and strides. So given Array!(2,int) A, A[all,5] and A[5,all] are both Array!(1,int) of the 6-th row and column of A. A[5,5] is an int. Some other neat features made possible by strided arrays are for instance A.diag, that returns the 1-dimensional diagonal of the array, so eg: A[] = 0; A.diag[] = 1; would construct the unit matrix.
 Basicly, the transformation is:

 $ => end
 a..b => range(a,b)

 I briefly described this in:
 news://news.digitalmars.com:119/eft9id$2aq3$1 digitaldaemon.com

former Matlab user. :-)

I wish I too could call myself a _former_ such. :) /Oskar
Dec 26 2006
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Oskar Linde wrote:
 == Quote from Bill Baxter (dnewsgroup billbaxter.com)'s article
 Oskar Linde wrote:
 Bill Baxter wrote:
 After trying to write a multi-dimensional array class, my opinion is
 that D slice support could use some upgrades overall.

own implementation of a multi-dimensional array type a couple of months ago, I came to the same conclusion. I posted about it in: news://news.digitalmars.com:119/edrv0n$hth$1 digitaldaemon.com http://www.digitalmars.com/d/archives/digitalmars/D/announce/4717.html
 What I'd like to see:

 * A way to have multiple ranges in a slice, and a mix slice of and
 non-slice indices:
     A[i..j, k..m]
     A[i..j, p, k..m]

     A[0..$,3..$]

language but not being allowed to utilize it... :) I work around this by instead using a custom slice syntax instead: A[range(i,j), range(k,m)] A[range(i,j), p, range(k,m)] A[range(0,end), range(3..end)] A[end-1, p % end]

guess that means you're using opIndex for everything and leaving opSlice alone.

Yes. Apart from the no-argument opSlice and opSliceAssign, that I overload with the same meaning as for the built in arrays. opSlice is not designed to support more than one dimension.
 Are you able to have ranges return arrays and specific indexes
 return scalar values that way?

Yes.
 That seems to me a big reason for having
 opSlice exist in the first place.  The .. in the brackets not only means
 you're slicing, it also means the function should return another array,
 versus returning an element.  That seems like a nice distinction to have
 to me.

Yes, definitely. My implementation mimics the behavior of the D native array/slice type (T[]), but extended for multiple dimensions and strides. So given Array!(2,int) A, A[all,5] and A[5,all] are both Array!(1,int) of the 6-th row and column of A. A[5,5] is an int. Some other neat features made possible by strided arrays are for instance A.diag, that returns the 1-dimensional diagonal of the array, so eg: A[] = 0; A.diag[] = 1; would construct the unit matrix.

Sounds great. Is your code available anywhere? --bb
Dec 26 2006
prev sibling next sibling parent Kevin Bealer <kevinbealer gmail.com> writes:
== Quote from Andrei Alexandrescu (See Website For Email)
(SeeWebsiteForEmail erdani.org)'s article
 Don Clugston wrote:
 Andrei Alexandrescu (See Website For Email) wrote:
 Similarly, let's say that a group of revolutionaries convinces Walter
 (as I understand happened in case of using "length" and "$" inside
 slice expressions, which is a shame and an absolute disaster that must
 be undone at all costs) to implement "auto"

This off-hand remark worries me. I presume that you mean being able to reference the length of a string, from inside the slice? (rather than simply the notation). And the problem being that it requires a sliceable entity to know its length? Or is the problem more serious than that? It's worrying because any change would break an enormous amount of code.

It would indeed break an enormous amount of code, but "all costs" includes "enormous costs". :o) A reasonable migration path is to deprecate them soon and make them illegal over the course of one year. A small book could be written on just how bad language design is using "length" and "$" to capture slice size inside a slice expression. I managed to write two lengthy emails to Walter about them, and just barely got started. Long story short, "length" introduces a keyword through the back door, effectively making any use of "length" anywhere unrecommended and highly fragile. Using "$" is a waste of symbolic real estate to serve a narrow purpose; the semantics isn't naturally generalized to its logical conclusion; and the choice of symbol itself as a reminiscent of Perl's regexp is at best dubious ("#" would have been vastly better as it has count connotation in natural language, and making it into an operator would have fixed the generalization issue). As things stand now, the rules governing the popping up of "length" and "$" constitute a sudden boo-boo on an otherwise carefully designed expression landscape.

I guess the question is, what is the best alternative. I agree about 'length', and I usually don't use "length" in this way, but I do things like x[$-2..$] all the time. Some proposals: 1. Symbols Going in the symbol direction, it might also make sense to *add* something like "^" for the start of a container. This would be useful with AAs and user defined types. We could use both: a[^+2..$-2]. This would only really be useful with containers that did not index from 0, i.e. non-integer or AA indices. char[char[]] words; words[^.."brink"]; // all words in dictionary before 'brink' words["brack"..$] // instead of symbols Which could translate to: words.opSlice(words.opBegin(), "brink") words.opSlice("brack", opEnd()) 2. I like this better: I call it "with without with" In order to maximize the dollar value :) of syntax symbol real estate, the meaning of $ could be expanded as follows: Something like X[$begin..$end] could be a shortcut for either X[0..X.length] for arrays, or X[X.opBegin()..X.opEnd()] for user types. I think the above solves the problem, doesn't it? The "$end" phrase is terse enough for most coders, unique enough to avoid namespace conflicts, avoids the problem of keywords ghosting in and out of existence in mid-expression, and avoids ruining $ (or # if #end is used instead) for the symbol space. We can stop right there... or go on to something for post-1.0: Other applications of $ could be: A. Syntax reduction for enumerated types and fields: struct Colors { enum { red, green, blue }; void set(int c); }; Colors c; c.set($red); This use of enumerated type is becoming more common, having "$" be a shortcut for <context>.X might make a lot of code more readable. The question then becomes, "Which contexts are searched for .X?" B. Reserved for language features. Leave this open for language designer use. All $xyz expressions are context dependent keywords. This allows much shorter words to be used, and allows language features to be named intelligently without worrying about crashing into user-defined names. For example, C could never introduce a new keyword called "begin" or "end", since it would break nearly every C program, but we can easily add a keyword called $begin which will not conflict with anything, since the $ saves us from conflicts. Most of the discussions for new features here have at least some arguments on how to add the new syntax for the feature, what other uses those symbols could be used for, etc. The $xyz route allows Walter to introduce lots of language concepts in the future without conflicts. It could even be used to prototype keywords that are experimental. They can even be removed or promoted to non-$ status later if desired. NOTE that if # was used instead of $, it would dovetail nicely with the "#line" and "#file" quasi-keywords.
 These issues you're raising seem to be far too fundamental to be fixed
 in the next few days, casting grave doubts on whether a D1.0 release on
 Jan 1 is a good idea.

The lvalue/rvalue issue is fundamental. I'm not in the position to assess whether it's a maker or breaker of D 1.0. The "length"/"$" issue is not fundamental the same way that C's declaration syntax, Java's throw specifications, C++'s use of "<" and ">" for templates, and Mao Zedong's refusal to use a toothbrush are not fundamental. It will "just" go down in history as a huge embarrassment and a good resource for cheap shooters and naysayers. If I understand its genesis, it will also be a canonical example of why design by committee is bad. Andrei

I like the terseness of "$" but I'm willing to do away with it if it really is that bad. What I'm wondering, is how far do you think we need to roll back the syntax, before it's "The Right Thing" (tm) again? Do we really need to go all the way to myarray[0..myarray.length], or can some intermediate solution work? Kevin
Dec 21 2006
prev sibling parent Steve Horne <stephenwantshornenospam100 aol.com> writes:
On Wed, 20 Dec 2006 06:24:28 -0800, "Andrei Alexandrescu (See Website
For Email)" <SeeWebsiteForEmail erdani.org> wrote:

Long story short, "length" introduces a keyword 
through the back door, effectively making any use of "length" anywhere 
unrecommended and highly fragile.

I've always had a strong feeling that all-lowercase words should be reserved as potential future keywords anyway, barring a few special cases like 'i'. I suppose a lot of that comes down to style, though. If you have a convention where most identifiers start with a capital (excluding prefixes like 'l_', 'p_' or 'm_'), that only really leaves common short non-descriptive names like 'i' as a special case. It's one of the things that bugs me about the normal Java style - it allows all-lowercase identifiers (only using capitals as word separators), which look like potential keywords if you're not too familiar with Java. Besides, from natural language convention, capitals should appear at the start of a sentence - having them in the middle of an sentence-like identifier but not at the start just looks wrong to me. -- Remove 'wants' and 'nospam' from e-mail.
Dec 22 2006
prev sibling parent reply Benji Smith <dlanguage benjismith.net> writes:
Andrei Alexandrescu (See Website For Email) wrote:
 Let me illustrate further why ident is important and what solution we 
 should have for it. Consider C's response to ident:
 
 #define IDENT(e) (e)
 
 ...

 ...leading to the following implementation of ident:
 
 auto ident(auto x) {
   return x;
 }

I don't get it. Why is it necessary (or even desirable) for functions to return lvalues? I can see how it'd be an interesting trick, and I can appreciate the experimental curiosity about how the language (and the implementation) should cope with the explicit handling of lvalues. But I can't think of a real-world use case. Are there languages where this is currently possible? How do they implement it? And, much more importantly, what do people use it for? --benji
Dec 20 2006
next sibling parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Benji Smith wrote:
 Andrei Alexandrescu (See Website For Email) wrote:
 Let me illustrate further why ident is important and what solution we 
 should have for it. Consider C's response to ident:

 #define IDENT(e) (e)

>
 ...leading to the following implementation of ident:

 auto ident(auto x) {
   return x;
 }

I don't get it. Why is it necessary (or even desirable) for functions to return lvalues?

For functions, I essentially agree. There aren't many use cases for it, and for the few niche ones a pointer will often suffice. But for methods of classes on the other hand, it can be valuable at times.
 Are there languages where this is currently possible?

C++, by returning a referance. -- Chris Nicholson-Sauls
Dec 20 2006
parent "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Chris Nicholson-Sauls wrote:
 Benji Smith wrote:
 Are there languages where this is currently possible?

C++, by returning a referance.

Perl 5 too. Andrei
Dec 21 2006
prev sibling next sibling parent "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Benji Smith wrote:
 Andrei Alexandrescu (See Website For Email) wrote:
 Let me illustrate further why ident is important and what solution we 
 should have for it. Consider C's response to ident:

 #define IDENT(e) (e)

>
 ...leading to the following implementation of ident:

 auto ident(auto x) {
   return x;
 }

I don't get it. Why is it necessary (or even desirable) for functions to return lvalues?

Methods might want to return lvalues, but indeed the need is not overwhelming. (They could return pointers after all.) But the point is different. You want to have a grip on all types, and ident shows that you can't. For example, in current D you can't (barring a hack that I saw in a post around here) have a template that takes a function and creates one of the exact signature. That is a vastly useful and desirable thing to want; think e.g. of a function that memoizes any other function. Andrei
Dec 21 2006
prev sibling next sibling parent Charles D Hixson <charleshixsn earthlink.net> writes:
Benji Smith wrote:
 Andrei Alexandrescu (See Website For Email) wrote:
 Let me illustrate further why ident is important and what solution we 
 should have for it. Consider C's response to ident:

 #define IDENT(e) (e)

>
 ...leading to the following implementation of ident:

 auto ident(auto x) {
   return x;
 }

I don't get it. Why is it necessary (or even desirable) for functions to return lvalues? I can see how it'd be an interesting trick, and I can appreciate the experimental curiosity about how the language (and the implementation) should cope with the explicit handling of lvalues. But I can't think of a real-world use case. Are there languages where this is currently possible? How do they implement it? And, much more importantly, what do people use it for? --benji

In PL/1 the substring function could be used as an lvalue. (Analogously, in D one can use array slices as lvalues.) I can't remember whether PL/1 allowed one to use this feature to delete characters, or only to alter them, but in Python one can use this feature to delete characters (or replace them with something that isn't a character?).
Dec 21 2006
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Benji Smith wrote:
 Andrei Alexandrescu (See Website For Email) wrote:
 Let me illustrate further why ident is important and what solution we 
 should have for it. Consider C's response to ident:

 #define IDENT(e) (e)

>
 ...leading to the following implementation of ident:

 auto ident(auto x) {
   return x;
 }

I don't get it. Why is it necessary (or even desirable) for functions to return lvalues? I can see how it'd be an interesting trick, and I can appreciate the experimental curiosity about how the language (and the implementation) should cope with the explicit handling of lvalues. But I can't think of a real-world use case. Are there languages where this is currently possible? How do they implement it? And, much more importantly, what do people use it for? --benji

There have been numerous cases here in the NG of people griping with this problem when using property-methods, or operator overloads such as opIndex, which both cannot return lvalues and thus have usage limitations. -- Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Dec 24 2006
prev sibling next sibling parent reply Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrei Alexandrescu (See Website for Email) schrieb am 2006-12-20:
 Kevin Bealer wrote:
 == Quote from Andrei Alexandrescu (See Website For Email)
 ...
 That remains to be seen, but I think the buck stops at functions. The
 problem of duplicating templates for inout (lvalues) and rvalues
 stays, but I have an idea about that, that I might tell about
 tomorrow.



<snip>
 We then discussed another solution that I won't bore you with, as it's 
 so wrong it hurts. My current thoughts navigate around two possible 
 solutions. One is to make the storage part of the template parameters:

 template ident(S T) {
    S T ident(S T e) { return e; }
 }

 When two adjacent symbols appear in a template parameter list, they 
 unambiguously denote a storage class followed by a type. So "S" can bind 
 to things like "in", "inout" etc., while "T" can bind to types.

Unambiguously? template Templ_1(int i) { } Is "int" now a type or a storage class?
 Another solution that works is to commit to the idea of associating the 
 storage class with the parameter (and divorce it from the type 
 entirely). In that case, the following syntax describes what happens:

 template ident(T) {
    storageof(e) T ident(storageof(e) T e) { return e; }
 }

 The storageof(symbol) meta-operator yields the storage of that symbol.

This seems to be much cleaner. How would storageof handle the following: mixin ident!(extern(C) inout float function(int)) foo; Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFFiUIQLK5blCcjpWoRAo38AJwNP1gCk52kIKuto9x76paeQq1LewCfUbrK zg3KJGIRH5wVoe/JeSR1aHE= =0HhD -----END PGP SIGNATURE-----
Dec 20 2006
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Thomas Kuehne wrote:
 We then discussed another solution that I won't bore you with, as it's 
 so wrong it hurts. My current thoughts navigate around two possible 
 solutions. One is to make the storage part of the template parameters:

 template ident(S T) {
    S T ident(S T e) { return e; }
 }

 When two adjacent symbols appear in a template parameter list, they 
 unambiguously denote a storage class followed by a type. So "S" can bind 
 to things like "in", "inout" etc., while "T" can bind to types.

Unambiguously? template Templ_1(int i) { } Is "int" now a type or a storage class?

It's a type because the symbol "int" is already bound as a keyword. There's no way (to the best of my knowledge) to specify two adjacent non-keyword symbols in a template parameter list.
 Another solution that works is to commit to the idea of associating the 
 storage class with the parameter (and divorce it from the type 
 entirely). In that case, the following syntax describes what happens:

 template ident(T) {
    storageof(e) T ident(storageof(e) T e) { return e; }
 }

 The storageof(symbol) meta-operator yields the storage of that symbol.

This seems to be much cleaner.

The more I think of it, the more I think it sucks :o).
 How would storageof handle the following:
 
 mixin ident!(extern(C) inout float function(int)) foo;

C does not have lvalue return types. Andrei
Dec 20 2006
parent reply Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrei Alexandrescu (See Website For Email) schrieb am 2006-12-20:
 Thomas Kuehne wrote:
 We then discussed another solution that I won't bore you with, as it's 
 so wrong it hurts. My current thoughts navigate around two possible 
 solutions. One is to make the storage part of the template parameters:

 template ident(S T) {
    S T ident(S T e) { return e; }
 }

 When two adjacent symbols appear in a template parameter list, they 
 unambiguously denote a storage class followed by a type. So "S" can bind 
 to things like "in", "inout" etc., while "T" can bind to types.

Unambiguously? template Templ_1(int i) { } Is "int" now a type or a storage class?

It's a type because the symbol "int" is already bound as a keyword. There's no way (to the best of my knowledge) to specify two adjacent non-keyword symbols in a template parameter list.

enum S{ FOO } template Templ(S T) { } mixin Templ!(S.FOO) bar; Do you consider S an keyword here? Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFFiWtKLK5blCcjpWoRAnRTAKCLuXgE7qH/OyabfPJ3aGaPRT0IaQCeLFy2 3PDyDfn8rcPDXpKq+m572HQ= =l6HF -----END PGP SIGNATURE-----
Dec 20 2006
parent "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Thomas Kuehne wrote:
 enum S{ FOO }
 template Templ(S T) { }
 mixin Templ!(S.FOO) bar;
 
 Do you consider S an keyword here?

You're right, it makes parsing dependent on the symbol table, breaking a nice property of D. Back to the drawing board. Andrei
Dec 21 2006
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Ohh, why didn't you start a new thread... I hate it when a thread gets 
so nested that one needs a widescreen monitor to view the topic list. :P

Andrei Alexandrescu (See Website for Email) wrote:
 Kevin Bealer wrote:
 == Quote from Andrei Alexandrescu (See Website For Email)
 ...
 That remains to be seen, but I think the buck stops at functions. The
 problem of duplicating templates for inout (lvalues) and rvalues
 stays, but I have an idea about that, that I might tell about
 tomorrow.

 Andrei

Did you ever work out how to do this lvalue/rvalue idea?

I had to leave to Romania before having the time to post thoughts on the lvalue/rvalue discussion I've had with Walter on Saturday. We both agree that it's a serious problem with D's type system that needs fixing (and that he needs to do all the work :o)). I've continued to think of the issue, at least enough to figure that the solution we initially thought of is not sound. Walter is reluctant to offering the ability to overload on lvalue/rvalue, while it turns out that that can't be avoided. Let's return to my litmus test - the identity function ident(e), which can snuggle any expression e and leave its semantics unchanged. My thesis is that this function is an important test of a language's power. The starting point would be: template ident(T) { T ident(T e) { return e; } inout T ident(inout T e) { return e; } } The problem with this approach is that it doesn't scale. Right now "inout" is about the only interesting storage class of a function parameter, but "lazy" comes to mind (which I hope to get rid of soon via a much better solution) and later on we'll have "const", and each of these combinations will mean one more duplication of the ident body (and, by extension, of any function that wants to just pass the storage class outside). Walter had an idea along the line:

Hum, I wonder if the 'lazy' "storage class" (it's not really a storage class per se) is something that is worth, or even makes sense preserving. If you want to completely preserve an expression, then what are the properties/characteristics of that expression? The type is one property of course, then there is if the expression is an rvalue or lvalue, and also if it is const/final/readonly or something like that. But 'lazy' is not something that is a property/characteristic of an expression is it? It is a concept that exists only in parameter passing of function calls. What would be an ident function trying to "preserve" the lazyness of an expression?..
 template ident(T) {
   return T ident(return T e) { return e; }
 }
 
 which allows you to reuse the return keyword as a symbolic placeholder 
 for passing out the storage class. This solution is severely 
 shortsighted in that it fixes ident and only ident, whereas the purpose 
 of ident is to serve as a simplified case for functions with multiple 
 parameters. So this fell as well.
 
 We then discussed another solution that I won't bore you with, as it's 
 so wrong it hurts. My current thoughts navigate around two possible 
 solutions. One is to make the storage part of the template parameters:
 
 template ident(S T) {
   S T ident(S T e) { return e; }
 }
 
 When two adjacent symbols appear in a template parameter list, they 
 unambiguously denote a storage class followed by a type. So "S" can bind 
 to things like "in", "inout" etc., while "T" can bind to types. In the 
 example above, the compiler will deduce both S and T from the argument 
 type. It already does that, so that's no extra difficulty. The key point 
 that makes this scale is that you can bind S and T multiple times in a 
 variadic template. Another interesting detail is that it clarifies that 
 you can't solve the problem without somehow compiling two versions of 
 the ident function. So in the end overloading on "inout" is a must.
 
 Another solution that works is to commit to the idea of associating the 
 storage class with the parameter (and divorce it from the type 
 entirely). In that case, the following syntax describes what happens:
 
 template ident(T) {
   storageof(e) T ident(storageof(e) T e) { return e; }
 }
 
 The storageof(symbol) meta-operator yields the storage of that symbol. 
 The problem with this notation is that it uses a symbol without having 
 seen it. That's not too bad (it already happens due to the way symbols 
 at global scope are looked up) but in this case it does have a fishy 
 smell. Another thing that I don't like it that the code obscures what's 
 going on - namely that one ident will be generated for each storage 
 class, even though that's not reflected in the parameter type list.
 
 Finally, one related but slightly different topic is the necessity of 
 deduced return types for functions, e.g. by using "auto" to denote the 
 return type. Automatic deduction of return types is very useful in that 
 it allows compact template function definition - no more need for a 
 template that defines a homonym function. With deduced argument types, 
 ident can be written as:
 
 auto ident(S T)(S T e) {
   return e;
 }
 
 which is, I think, the Platonic ideal of ident as far as expressing it 
 in D goes.
 
 
 Andrei

Hum, interesting. I've seen this issue come up in another context as well, namely a paper about a proposal (Javari) for the addition of a reference immutability construct to Java, in the form of a 'const'-like keyword called 'readonly'. Since 'readonly' is very like (the future) 'inout', as they are both "type modifiers" of sorts, with similar syntax, they too had the issue of trying to avoid function definition duplication where only the absence or presence of 'readonly' changed in the prototype. Their solution was similar to the above. But instead of a "storage class" modifier variable like S, they used a keyword ('romaybe'), so that a templated function would be defined as this: romaybe Object getValue(romaybe thisojb) { return thisojb.value; } Which would generate two function instances, one where 'romaybe' is substituted by 'readonly' and other where it is substituted with nothing (which is mutability). The difference between the "storage class" modifier variable syntax is that only one "storage class" [*] can be parameterized, i.e., you can't have S1, S2, etc. [*] we really should not be calling this, "storage class". -- Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Dec 26 2006
prev sibling parent reply "Andrei Alexandrescu (See Website for Email)" <SeeWebsiteForEmail erdani.org> writes:
Lionello Lunesu wrote:
 Walter Bright wrote:
 It is possible to force the return type of opAssign. But I'd suggest 
 making it an S*, with the rewrite to:

     *(a.opAssign(b))

class C { C* opAssign(...) {...} } struct S { S* opAssign(...) {...} } Seriously?? Ugh. Why not just "C opAssign" and "S opAssign"? In the opCall discussion you said yourself that the return value will be optimized. Am I missing something?

There is no *extra* copying, in the sense that exactly one copy is done. But most of the time the copy obtained is not used, in which case that one copy is spurious. Andrei
Dec 14 2006
parent reply Lionello Lunesu <lio lunesu.remove.com> writes:
Andrei Alexandrescu (See Website for Email) wrote:
 Lionello Lunesu wrote:
 Walter Bright wrote:
 It is possible to force the return type of opAssign. But I'd suggest 
 making it an S*, with the rewrite to:

     *(a.opAssign(b))

class C { C* opAssign(...) {...} } struct S { S* opAssign(...) {...} } Seriously?? Ugh. Why not just "C opAssign" and "S opAssign"? In the opCall discussion you said yourself that the return value will be optimized. Am I missing something?

There is no *extra* copying, in the sense that exactly one copy is done. But most of the time the copy obtained is not used, in which case that one copy is spurious.

I'd think that the optimizer would not only eliminate the extra copy, but the entire construction of the return value .. No? L.
Dec 15 2006
parent Sean Kelly <sean f4.ca> writes:
Lionello Lunesu wrote:
 Andrei Alexandrescu (See Website for Email) wrote:
 Lionello Lunesu wrote:
 Walter Bright wrote:
 It is possible to force the return type of opAssign. But I'd suggest 
 making it an S*, with the rewrite to:

     *(a.opAssign(b))

class C { C* opAssign(...) {...} } struct S { S* opAssign(...) {...} } Seriously?? Ugh. Why not just "C opAssign" and "S opAssign"? In the opCall discussion you said yourself that the return value will be optimized. Am I missing something?

There is no *extra* copying, in the sense that exactly one copy is done. But most of the time the copy obtained is not used, in which case that one copy is spurious.

I'd think that the optimizer would not only eliminate the extra copy, but the entire construction of the return value .. No?

If the routine is inlined perhaps, but otherwise not. Sean
Dec 15 2006
prev sibling parent "Andrei Alexandrescu (See Website for Email)" <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:
 Andrei Alexandrescu (See Website For Email) wrote:
 Require opAssign() to always return void and have the compiler return 
 a reference to the left-hand side. That is, transform:

 a = b;

 into:

 (a.opAssign(b), a);

 with the mention that a only gets evaluated once.

 This way assignment _always_ returns its left-hand side and user code 
 cannot subvert that behavior. Also the code will be efficient because 
 no more spurious copies are being made.

It is possible to force the return type of opAssign. But I'd suggest making it an S*, with the rewrite to: *(a.opAssign(b))

Makes sense, but then I keep on racking my brain to ever think of any C++ code that ever return something else than *this. Never saw any, never wrote any - ever. So I just conclude that customizing =, +=, -= etc. is a good thing, but customizing their return type and value is not. Adding the silly "return this;" litany at the end of every single operator is not something for a language that wants to do things the right way. The speed will be better, too. It's kind of annoying to know that I can't write: a = b; and simply have the compiler do what it takes and no more. Every of those spurious copies is just some more discomfort I have to put in. Andrei
Dec 14 2006
prev sibling parent reply Kevin Bealer <kevinbealer gmail.com> writes:
== Quote from Andrei Alexandrescu (See Website For Email)
(SeeWebsiteForEmail erdani.org)'s article
 Walter Bright wrote:
 Andrei Alexandrescu (See Website for Email) wrote:

 That makes me wonder - if a = b is used without picking up its result
 (the usual case), and if opAssign() returns an S, will the compiler
 optimize away the extra copy at zero cost?

No. The caller and callee don't know about each other.
 What I think happens is that the function will take a pointer to the
 destination which is zero, so a comparison will be made. But perhaps
 the optimizer will take care of eliminating that?

You could have a null pointer passed to the return result, but that would entail an extra check on the part of the callee. This is why a lot of C++ code tends to return references instead of values.

that returns void, might be worth looking into. Because right now user code for opAssign() can't be politically correct and efficient at the same time. Here's a better alternative: Require opAssign() to always return void and have the compiler return a reference to the left-hand side. That is, transform: a = b; into: (a.opAssign(b), a); with the mention that a only gets evaluated once. This way assignment _always_ returns its left-hand side and user code cannot subvert that behavior. Also the code will be efficient because no more spurious copies are being made. Andrei

I wonder, are there cases where assignment should not return 'this'? What I'm thinking of is something like: class StringExpression { ... holds equations between strings }; class String { // wrapper around char[] StringExpression opCat(String x); StringExpression opCat(StringExpression x); }; This 'expression-class' stuff is done more commonly with matrices, where the programmer is trying to to combine multiplies and adds via some optimization rules. Since C++ at least is flexible (syntax wise at least) on operator inputs and outputs, I have to wonder if there are really consequences for not following those expectations here. Imagine a string expression like this: a = b ~ (c = d ~ e); Now if I can do "StringExpression String::opAssign(...)", this could maybe be rewritten (code not shown...) to result in something like this: a = b ~ d ~ e; c = a[b.length..a.length]; Not that this is worth the effort or that the language should do this with strings, but as a programmer, can I reasonably do this kind of trick with operator return values or am I just digging a hole for myself? (I realize that even if useful it may not be worthwhile.) Kevin
Dec 14 2006
parent Sean Kelly <sean f4.ca> writes:
Kevin Bealer wrote:
 == Quote from Andrei Alexandrescu (See Website For Email)
 (SeeWebsiteForEmail erdani.org)'s article
 Here's a better alternative:
 Require opAssign() to always return void and have the compiler return a
 reference to the left-hand side. That is, transform:
 a = b;
 into:
 (a.opAssign(b), a);
 with the mention that a only gets evaluated once.
 This way assignment _always_ returns its left-hand side and user code
 cannot subvert that behavior. Also the code will be efficient because no
 more spurious copies are being made.

I wonder, are there cases where assignment should not return 'this'?

I've been thinking the same thing, and so far haven't been able to come up with an example where "correct" use of an assignment operator should not return 'this'. I was considering suggestion the same thing as Andrei above, but was hoping someone would post a counterexample in the interim :-) About the only weird thing with returning void and allowing this: a = b = c; Is that it isn't equivalent to this: a.opAssign( b.opAssign( c ) ); Which may be a bit confusing. But it does seem quite natural that the result of an assignment should always be the LHS of the assignment. Sean
Dec 14 2006
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Walter Bright wrote:
 Stewart Gordon wrote:

 The programmer would have a choice - opAssign returning void to modify 
 in-place the object referenced by the lvalue, or returning a new 
 object that will be assigned to the lvalue.  What is this precluding?

opAssign has 3 externally visible characteristics: 1) the parameter 2) the 'this' pointer 3) the return value Your proposal mixes up 2 and 3. opAssign works like: a = b becomes: a.opAssign(b) The return value is not assigned to a, it is the value of the expression (a = b). Mixing up the return value and the assignment to a will cause problems, as the two are different things, and should be independent.

C'mon, what's your use case for being allowed to return something other than the new value of a from the expression (a = b)? Stewart.
Dec 14 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Stewart Gordon wrote:
 C'mon, what's your use case for being allowed to return something other 
 than the new value of a from the expression (a = b)?

I don't have one. But I prefer to impose as few restrictions as possible, as people keep finding unanticipated cool new things to do. So I'd argue that there should be compelling case put forward to impose such a restriction, rather than wondering what one can do with the flexibility.
Dec 14 2006
next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Walter Bright wrote:
 Stewart Gordon wrote:
 C'mon, what's your use case for being allowed to return something 
 other than the new value of a from the expression (a = b)?

I don't have one. But I prefer to impose as few restrictions as possible, as people keep finding unanticipated cool new things to do. So I'd argue that there should be compelling case put forward to impose such a restriction, rather than wondering what one can do with the flexibility.

For one, it might be useful to return some sort of proxy for 'a'. --bb
Dec 14 2006
prev sibling next sibling parent "Andrei Alexandrescu (See Website for Email)" <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:
 Stewart Gordon wrote:
 C'mon, what's your use case for being allowed to return something 
 other than the new value of a from the expression (a = b)?

I don't have one. But I prefer to impose as few restrictions as possible, as people keep finding unanticipated cool new things to do. So I'd argue that there should be compelling case put forward to impose such a restriction, rather than wondering what one can do with the flexibility.

Just did so in my previous post. Andrei
Dec 14 2006
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Walter Bright wrote:
 Stewart Gordon wrote:
 C'mon, what's your use case for being allowed to return something 
 other than the new value of a from the expression (a = b)?

I don't have one. But I prefer to impose as few restrictions as possible, as people keep finding unanticipated cool new things to do. So I'd argue that there should be compelling case put forward to impose such a restriction, rather than wondering what one can do with the flexibility.

We already have what strikes the rest of us as a compelling case: what we've just told you that returning from opAssign _should_ be able to do. Stewart.
Dec 14 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Stewart Gordon wrote:
 We already have what strikes the rest of us as a compelling case: what 
 we've just told you that returning from opAssign _should_ be able to do.

That case was trying to make opAssign be a constructor. Since there are other ways to construct it, I don't see why it's a compelling case. What is bought with this that cannot be otherwise done?
Dec 14 2006
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Walter Bright wrote:
 Stewart Gordon wrote:
 We already have what strikes the rest of us as a compelling case: what 
 we've just told you that returning from opAssign _should_ be able to do.

That case was trying to make opAssign be a constructor. Since there are other ways to construct it, I don't see why it's a compelling case. What is bought with this that cannot be otherwise done?

The cases you seemingly pander to for having opAssign in the first place are trying to make opAssign be a property setter. Since there are other ways to set properties, I don't see why this is a compelling case. What is bought with this that cannot be otherwise done? Stewart.
Dec 15 2006
prev sibling next sibling parent reply "Chris Miller" <chris dprogramming.com> writes:
char* p =3D new char[32];

Error: cannot implicitly convert expression (new char[](32)) of type  =

char[] to char*

Should this be a special case? Currently it needs  (new char[32]).ptr
Dec 09 2006
next sibling parent reply Alexander Panek <a.panek brainsware.org> writes:
char *newCharz( uint size ) {
	return (new char [size]).ptr;
}

char *p = newCharz(32);

:P

I like the explicity.

Chris Miller wrote:
 
 char* p = new char[32];
 
 Error: cannot implicitly convert expression (new char[](32)) of type 
 char[] to char*
 
 Should this be a special case? Currently it needs  (new char[32]).ptr

Dec 09 2006
parent reply "Chris Miller" <chris dprogramming.com> writes:
On Sat, 09 Dec 2006 11:33:17 -0500, Alexander Panek  =

<a.panek brainsware.org> wrote:

 char *newCharz( uint size ) {
 	return (new char [size]).ptr;
 }

 char *p =3D newCharz(32);

 :P

 I like the explicity.

Well, I'm not sure what it should be, but you already made a mistake: it= = should be size_t instead of uint ;) Plus, I never said it was a zero-terminated string.
 Chris Miller wrote:
  char* p =3D new char[32];
  Error: cannot implicitly convert expression (new char[](32)) of type=


 char[] to char*
  Should this be a special case? Currently it needs  (new char[32]).pt=


Dec 09 2006
parent reply Alexander Panek <a.panek brainsware.org> writes:
Chris Miller wrote:
 On Sat, 09 Dec 2006 11:33:17 -0500, Alexander Panek 
 <a.panek brainsware.org> wrote:
 
 char *newCharz( uint size ) {
     return (new char [size]).ptr;
 }

 char *p = newCharz(32);

 :P

 I like the explicity.

Well, I'm not sure what it should be, but you already made a mistake: it should be size_t instead of uint ;) Plus, I never said it was a zero-terminated string.

Oi. Sorry: char * toChars( size_t size ) { return (new char[size]).ptr; } char * toCharz( size_t size ) { return (new char[size + 1]).ptr; } Better? :P
 
 Chris Miller wrote:
  char* p = new char[32];
  Error: cannot implicitly convert expression (new char[](32)) of type 
 char[] to char*
  Should this be a special case? Currently it needs  (new char[32]).ptr



Dec 09 2006
parent reply Alexander Panek <a.panek brainsware.org> writes:
Those are newCharz and newChars, of course.

Apart from that, this might be interesting, too:

// alias thingie array;

template Ptr (T) {
	// Create a simple thingie
	T *newPtrs ( size_t size ) {
		return (new T[size]).ptr;
	}

	// Create null-terminated thingie
	T *newPtrz ( size_t size ) {
		T *p = (new T[size + 1]).ptr
		p[$ - 1] = '\0';

		return p;
	}
}

alias Ptr!(char).newPtrs newChars;
alias Ptr!(char).newPtrz newCharz;

Not tested, but this might be useful for someone.

Alexander Panek wrote:
 Chris Miller wrote:
 On Sat, 09 Dec 2006 11:33:17 -0500, Alexander Panek 
 <a.panek brainsware.org> wrote:

 char *newCharz( uint size ) {
     return (new char [size]).ptr;
 }

 char *p = newCharz(32);

 :P

 I like the explicity.

Well, I'm not sure what it should be, but you already made a mistake: it should be size_t instead of uint ;) Plus, I never said it was a zero-terminated string.

Oi. Sorry: char * toChars( size_t size ) { return (new char[size]).ptr; } char * toCharz( size_t size ) { return (new char[size + 1]).ptr; } Better? :P
 Chris Miller wrote:
  char* p = new char[32];
  Error: cannot implicitly convert expression (new char[](32)) of 
 type char[] to char*
  Should this be a special case? Currently it needs  (new char[32]).ptr




Dec 09 2006
parent "Chris Miller" <chris dprogramming.com> writes:
On Sat, 09 Dec 2006 11:53:07 -0500, Alexander Panek  =

<a.panek brainsware.org> wrote:

 Those are newCharz and newChars, of course.

 Apart from that, this might be interesting, too:

 // alias thingie array;

 template Ptr (T) {
 	// Create a simple thingie
 	T *newPtrs ( size_t size ) {
 		return (new T[size]).ptr;
 	}

 	// Create null-terminated thingie
 	T *newPtrz ( size_t size ) {
 		T *p =3D (new T[size + 1]).ptr
 		p[$ - 1] =3D '\0';

 		return p;
 	}
 }

 alias Ptr!(char).newPtrs newChars;
 alias Ptr!(char).newPtrz newCharz;

 Not tested, but this might be useful for someone.

Not bad, perhaps needs better names though. newChars still sounds like n= ew = char[] (array). Maybe allocptr/ptrAlloc/ptralloc/palloc to have a simila= r = name as malloc since they have similarities (working with pointers). = *shrug*
Dec 09 2006
prev sibling parent Pragma <ericanderton yahoo.removeme.com> writes:
Chris Miller wrote:
 
 char* p = new char[32];
 
 Error: cannot implicitly convert expression (new char[](32)) of type 
 char[] to char*
 
 Should this be a special case? Currently it needs  (new char[32]).ptr

Well, the problem is that since this change, char[] is not the same thing as char*; IMO, this is a good thing. You really should have to jump through an extra hoop to get there, because they're not the same. It's no different than a cast, if it is a little harder to type. -- - EricAnderton at yahoo
Dec 11 2006
prev sibling next sibling parent reply Burton Radons <burton-radons smocky.com> writes:
- Casting a value v to a struct S is now rewritten as S(v).

I'm 100% against this. This is what C++ does, and it conflates 
construction and casting; with some VERY simple examples (such as the 
first one we think of when we think of additional types, bignums), 
there's an ambiguous conflict because one of the constructors should 
have a count of how many digits you want - and one of the casters takes 
an integer for a value to initialise to. My solution at the time was to 
add a dummy argument to the constructor so that the compiler didn't try 
to match them, which is absurd.

I don't know why C++ was designed like this when its error was so 
blatant, but D doesn't need to replicate its mistake. "S.opCastFrom (v)" 
please, except that it shouldn't be static either.
Dec 09 2006
parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Burton Radons wrote:
 - Casting a value v to a struct S is now rewritten as S(v).
 
 I'm 100% against this. This is what C++ does, and it conflates 
 construction and casting; with some VERY simple examples (such as the 
 first one we think of when we think of additional types, bignums), 
 there's an ambiguous conflict because one of the constructors should 
 have a count of how many digits you want - and one of the casters takes 
 an integer for a value to initialise to. My solution at the time was to 
 add a dummy argument to the constructor so that the compiler didn't try 
 to match them, which is absurd.
 
 I don't know why C++ was designed like this when its error was so 
 blatant, but D doesn't need to replicate its mistake. "S.opCastFrom (v)" 
 please, except that it shouldn't be static either.

Essentially agreed. I'm not entirely fond of the "silent" new opAssign either, because of the visual ambiguity it can lead to. (Its worth noting that, even though '='->opAssign is listed in the spec, the bottom of the same page still lists '=' among the operators which will not be given overloads. Hm.) -- Chris Nicholson-Sauls
Dec 09 2006
parent reply Sean Kelly <sean f4.ca> writes:
Chris Nicholson-Sauls wrote:
 Burton Radons wrote:
 - Casting a value v to a struct S is now rewritten as S(v).

 I'm 100% against this. This is what C++ does, and it conflates 
 construction and casting; with some VERY simple examples (such as the 
 first one we think of when we think of additional types, bignums), 
 there's an ambiguous conflict because one of the constructors should 
 have a count of how many digits you want - and one of the casters 
 takes an integer for a value to initialise to. My solution at the time 
 was to add a dummy argument to the constructor so that the compiler 
 didn't try to match them, which is absurd.

 I don't know why C++ was designed like this when its error was so 
 blatant, but D doesn't need to replicate its mistake. "S.opCastFrom 
 (v)" please, except that it shouldn't be static either.

Essentially agreed. I'm not entirely fond of the "silent" new opAssign either, because of the visual ambiguity it can lead to. (Its worth noting that, even though '='->opAssign is listed in the spec, the bottom of the same page still lists '=' among the operators which will not be given overloads. Hm.)

Same. And frankly, I'm having trouble coming up with a practical use for the new opAssign. For one thing, it isn't commutative: auto c = new MyClass; int i = 5; c = i; // will work i = c; // won't work And now structs have an opAssign but still have binary copy semantics and no ctor/dtor support. The result is totally confusing. What was the use case for this feature? Sean
Dec 09 2006
parent Leopold Walkling <leopold_walkling web.de> writes:
Sean Kelly schrieb:
 Chris Nicholson-Sauls wrote:
 Burton Radons wrote:
 - Casting a value v to a struct S is now rewritten as S(v).

 I'm 100% against this. This is what C++ does, and it conflates 
 construction and casting; with some VERY simple examples (such as the 
 first one we think of when we think of additional types, bignums), 
 there's an ambiguous conflict because one of the constructors should 
 have a count of how many digits you want - and one of the casters 
 takes an integer for a value to initialise to. My solution at the 
 time was to add a dummy argument to the constructor so that the 
 compiler didn't try to match them, which is absurd.

 I don't know why C++ was designed like this when its error was so 
 blatant, but D doesn't need to replicate its mistake. "S.opCastFrom 
 (v)" please, except that it shouldn't be static either.

Essentially agreed. I'm not entirely fond of the "silent" new opAssign either, because of the visual ambiguity it can lead to. (Its worth noting that, even though '='->opAssign is listed in the spec, the bottom of the same page still lists '=' among the operators which will not be given overloads. Hm.)

Same. And frankly, I'm having trouble coming up with a practical use for the new opAssign. For one thing, it isn't commutative: auto c = new MyClass; int i = 5; c = i; // will work i = c; // won't work And now structs have an opAssign but still have binary copy semantics and no ctor/dtor support. The result is totally confusing. What was the use case for this feature? Sean

Why are opAssign overloads possible for structs? They lead to a bad style like the example above: It's possible to assign a primitive type to an aggregate type, without showing what is done in the code.
Dec 09 2006
prev sibling next sibling parent "John Reimer" <terminal.node gmail.com> writes:
On Sat, 09 Dec 2006 02:20:00 -0800, Walter Bright  =

<newshound digitalmars.com> wrote:

 More ABI changes, and implicit [] =3D> * no longer allowed.

 http://www.digitalmars.com/d/changelog.html

 http://ftp.digitalmars.com/dmd.175.zip

um... but this is the link for dmd.175.zip again, not 177. -JJR
Dec 09 2006
prev sibling next sibling parent pmoore <some_email_addr example.com> writes:
Thanks for this. But std.demangle seems to be broken now.
Dec 09 2006
prev sibling next sibling parent reply "David L. Davis" <SpottedTiger yahoo.com> writes:
Walter in dmd v0.176 you improved name mangling, but I've found one very 
confusing change...is it your intension to reuse the "b" which used to mean 
"bit," to now mean a "bool" instead of "x?"

For example, one function "real vdb(real, real, real, real, real, real, bool 
= false)" used in my financial D dll,
before dmd v0.148 was released when the "bool" data type was added 
(replacing the "bit" data type) the function's mangled name was 
"D13financial_dll3vdbFeeeeeebZe". And with dmd v0.148 and later, the "bit" 
data type become an alias to bool and all the "b" (for "bit") were replaced 
with "x" (for "bool"), thus the funtion's mangled name changed to become 
"D13financial_dll3vdbFeeeeeexZe". But now it looks like "x" has been 
replaced by "b," is this a mistake on your part, or have you decided to use 
a "b" as meaning a "bool" (discarding "x")?

So currently the "vdb()" funtion under dmd v0.177 has returned to the old 
mangled name "D13financial_dll3vdbFeeeeeebZe," as if a "bool" has become a 
"bit" again.

Thanks again for all the great work you've been putting into D year after 
year!

David L.
-------------------------------------------------------------------
"Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"
-------------------------------------------------------------------

MKoD: http://spottedtiger.tripod.com/D_Language/D_Main_XP.html
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:ele2k9$2hr5$1 digitaldaemon.com...
 More ABI changes, and implicit [] => * no longer allowed.

 http://www.digitalmars.com/d/changelog.html

 http://ftp.digitalmars.com/dmd.175.zip 

Dec 09 2006
next sibling parent Walter Bright <newshound digitalmars.com> writes:
David L. Davis wrote:
 Walter in dmd v0.176 you improved name mangling, but I've found one very 
 confusing change...is it your intension to reuse the "b" which used to mean 
 "bit," to now mean a "bool" instead of "x?"

That's what people asked for.
 For example, one function "real vdb(real, real, real, real, real, real, bool 
 = false)" used in my financial D dll,
 before dmd v0.148 was released when the "bool" data type was added 
 (replacing the "bit" data type) the function's mangled name was 
 "D13financial_dll3vdbFeeeeeebZe". And with dmd v0.148 and later, the "bit" 
 data type become an alias to bool and all the "b" (for "bit") were replaced 
 with "x" (for "bool"), thus the funtion's mangled name changed to become 
 "D13financial_dll3vdbFeeeeeexZe". But now it looks like "x" has been 
 replaced by "b," is this a mistake on your part, or have you decided to use 
 a "b" as meaning a "bool" (discarding "x")?

That's correct.
 So currently the "vdb()" funtion under dmd v0.177 has returned to the old 
 mangled name "D13financial_dll3vdbFeeeeeebZe," as if a "bool" has become a 
 "bit" again.

Yes. There's no going back to bit.
 Thanks again for all the great work you've been putting into D year after 
 year!

You're most welcome.
Dec 09 2006
prev sibling parent reply Don Clugston <dac nospam.com.au> writes:
David L. Davis wrote:
 Walter in dmd v0.176 you improved name mangling, but I've found one very 
 confusing change...is it your intension to reuse the "b" which used to mean 
 "bit," to now mean a "bool" instead of "x?"

 For example, one function "real vdb(real, real, real, real, real, real, bool 
 = false)" used in my financial D dll,
 before dmd v0.148 was released when the "bool" data type was added 
 (replacing the "bit" data type) the function's mangled name was 
 "D13financial_dll3vdbFeeeeeebZe". And with dmd v0.148 and later, the "bit" 
 data type become an alias to bool and all the "b" (for "bit") were replaced 
 with "x" (for "bool"), thus the funtion's mangled name changed to become 
 "D13financial_dll3vdbFeeeeeexZe". But now it looks like "x" has been 
 replaced by "b," is this a mistake on your part, or have you decided to use 
 a "b" as meaning a "bool" (discarding "x")?

Between 0.148 and 0.175, function pointers used 'b' for 'bool', but the functions themselves used 'x'. It was a bit inconsistent.
Dec 10 2006
parent "David L. Davis" <SpottedTiger yahoo.com> writes:
Don thanks for clarifying the reason, I didn't know about the function 
pointers still using 'b' after bool replaced bit. It all now makes a lot 
more sense as to the why change happened the way it did.

David L.
-------------------------------------------------------------------
"Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"
-------------------------------------------------------------------

MKoD: http://spottedtiger.tripod.com/D_Language/D_Main_XP.html

"Don Clugston" <dac nospam.com.au> wrote in message 
news:elho1o$t1d$1 digitaldaemon.com...
 David L. Davis wrote:
 Walter in dmd v0.176 you improved name mangling, but I've found one very 
 confusing change...is it your intension to reuse the "b" which used to 
 mean "bit," to now mean a "bool" instead of "x?"

 For example, one function "real vdb(real, real, real, real, real, real, 
 bool = false)" used in my financial D dll,
 before dmd v0.148 was released when the "bool" data type was added 
 (replacing the "bit" data type) the function's mangled name was 
 "D13financial_dll3vdbFeeeeeebZe". And with dmd v0.148 and later, the 
 "bit" data type become an alias to bool and all the "b" (for "bit") were 
 replaced with "x" (for "bool"), thus the funtion's mangled name changed 
 to become "D13financial_dll3vdbFeeeeeexZe". But now it looks like "x" has 
 been replaced by "b," is this a mistake on your part, or have you decided 
 to use a "b" as meaning a "bool" (discarding "x")?

Between 0.148 and 0.175, function pointers used 'b' for 'bool', but the functions themselves used 'x'. It was a bit inconsistent.

Dec 12 2006
prev sibling next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:ele2k9$2hr5$1 digitaldaemon.com...
 More ABI changes, and implicit [] => * no longer allowed.

 http://www.digitalmars.com/d/changelog.html

 http://ftp.digitalmars.com/dmd.175.zip

No offense, but would it honestly kill you to allow ctors in structs? We've been using static opCall as a _workaround_ for the lack of struct ctors, and making it part of the language doesn't really seem to be addressing the problem. That, and it doesn't make any sense that classes use "this()" and structs use "static S opCall()". We're starting to get into "overloading indexing in C++" territory. That, and which would be more efficient? The static opCall needs to return an instance of the struct on the stack, which could be very inefficient for large structs. With a true ctor, the struct is passed by reference to the ctor and has its fields set directly. And I also can't figure out how to make the implicit opCall work with more than one parameter. :P I'm also a little wary about opAssign. Not that I don't find it useful, just that you've been vehemently opposed to overloading it in D for how many years, and three weeks before 1.0 you reverse your opinion. What does that mean? But complaints aside, thanks for removing the []=>* implicit cast and the bugfixes. Man, this last month has been an exciting time for D :)
Dec 09 2006
next sibling parent Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Jarrett Billingsley wrote:
 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:ele2k9$2hr5$1 digitaldaemon.com...
 
More ABI changes, and implicit [] => * no longer allowed.

http://www.digitalmars.com/d/changelog.html

http://ftp.digitalmars.com/dmd.175.zip

No offense, but would it honestly kill you to allow ctors in structs? We've been using static opCall as a _workaround_ for the lack of struct ctors, and making it part of the language doesn't really seem to be addressing the problem. That, and it doesn't make any sense that classes use "this()" and structs use "static S opCall()". We're starting to get into "overloading indexing in C++" territory. That, and which would be more efficient? The static opCall needs to return an instance of the struct on the stack, which could be very inefficient for large structs. With a true ctor, the struct is passed by reference to the ctor and has its fields set directly. And I also can't figure out how to make the implicit opCall work with more than one parameter. :P I'm also a little wary about opAssign. Not that I don't find it useful, just that you've been vehemently opposed to overloading it in D for how many years, and three weeks before 1.0 you reverse your opinion. What does that mean?

The thing with opAssign, I realised after reading the spec, is that it explicitly doesn't allow copy assignment. This reduces it from the level of a powerful feature to a mere toy, or at most a form of implicit casting. Assigning one struct to another still guarantees a bitwise copy, and reference assignment for class instances cannot be stepped on. This removes essentially all of the danger that opAssign might have introduced.
 But complaints aside, thanks for removing the []=>* implicit cast and the 
 bugfixes.  Man, this last month has been an exciting time for D :) 
 
 

-- Kirk McDonald Pyd: Wrapping Python with D http://pyd.dsource.org
Dec 09 2006
prev sibling next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Jarrett Billingsley wrote:
 No offense, but would it honestly kill you to allow ctors in structs?  We've 
 been using static opCall as a _workaround_ for the lack of struct ctors, and 
 making it part of the language doesn't really seem to be addressing the 
 problem.  That, and it doesn't make any sense that classes use "this()" and 
 structs use "static S opCall()".  We're starting to get into "overloading 
 indexing in C++" territory.

It turns out that static opCall() and this() are equivalent. C++ has some obscure rules to try to disambiguate them. I wished to avoid that problem, and since static opCall() is routinely in use, picked them.
 That, and which would be more efficient?  The static opCall needs to return 
 an instance of the struct on the stack, which could be very inefficient for 
 large structs.  With a true ctor, the struct is passed by reference to the 
 ctor and has its fields set directly.

The optimizer removes the redundant copy, and builds the result directly into the target.
 And I also can't figure out how to make the implicit opCall work with more 
 than one parameter.  :P

S(1,2,3)
 I'm also a little wary about opAssign.  Not that I don't find it useful, 
 just that you've been vehemently opposed to overloading it in D for how many 
 years, and three weeks before 1.0 you reverse your opinion.  What does that 
 mean?

The problem I have, and still have, is the identity assignment. This is specifically disallowed with opAssign. I can go into the reasons why if you like. Having opAssign for foreign types turns out to be needed for things like, say I want to build a ranged integer. This is an integer that can only have values between m and n. Without opAssign, I'd have to use a property: RangedInt!(m,n) r; r.value = 6; It's just not right.
 But complaints aside, thanks for removing the []=>* implicit cast and the 
 bugfixes.  Man, this last month has been an exciting time for D :) 

For me as well!
Dec 09 2006
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:elf9mn$snp$1 digitaldaemon.com...

 It turns out that static opCall() and this() are equivalent. C++ has some 
 obscure rules to try to disambiguate them. I wished to avoid that problem, 
 and since static opCall() is routinely in use, picked them.

For classes they're not. Why should structs be any different? And even if static opCalls are routinely in use, are they the best solution? And are they _really_ equivalent? Where's the 'this' pointer in a static opCall()?
 The optimizer removes the redundant copy, and builds the result directly 
 into the target.

Wouldn't it be easier to just have ctors, so implementations don't have to worry about writing an optimizer just to support this behavior?
 And I also can't figure out how to make the implicit opCall work with 
 more than one parameter.  :P

S(1,2,3)

Oh. I was thinking more along the lines of being able to do "S s(1, 2, 3);".
 The problem I have, and still have, is the identity assignment. This is 
 specifically disallowed with opAssign. I can go into the reasons why if 
 you like.

 Having opAssign for foreign types turns out to be needed for things like, 
 say I want to build a ranged integer. This is an integer that can only 
 have values between m and n. Without opAssign, I'd have to use a property:
 RangedInt!(m,n) r;
 r.value = 6;
 It's just not right.

That makes sense. It gives the utility of opAssign in most cases without the scary stuff. Though as was mentioned elsewhere, it's not commutative, so it's still not possible to do RangedInt!(m, n) r; r = 5; int x = r; // error :/
 But complaints aside, thanks for removing the []=>* implicit cast and the 
 bugfixes.  Man, this last month has been an exciting time for D :)

For me as well!

Dec 09 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Jarrett Billingsley wrote:
 It turns out that static opCall() and this() are equivalent. C++ has some 
 obscure rules to try to disambiguate them. I wished to avoid that problem, 
 and since static opCall() is routinely in use, picked them.

static opCalls are routinely in use, are they the best solution?

I've found they work well.
 And are they _really_ equivalent?

Not perfectly, but the differences are small.
 Where's the 'this' pointer in a static 
 opCall()?

It's in your return value.
 The optimizer removes the redundant copy, and builds the result directly 
 into the target.

worry about writing an optimizer just to support this behavior?

You have to have the optimization anyway. My C++ compiler has had it since 1991 or so. It's oooold technology.
 And I also can't figure out how to make the implicit opCall work with 
 more than one parameter.  :P


Oh. I was thinking more along the lines of being able to do "S s(1, 2, 3);".

I prefer: auto s = S(1,2,3); to C++ style. static opCall fits right in.
 Though as was mentioned elsewhere, it's not commutative, so it's still not 
 possible to do
 
 RangedInt!(m, n) r;
 r = 5;
 int x = r; // error

That's implicit casting from a struct. It'll probably wind up getting supported in one form or another.
Dec 09 2006
next sibling parent reply Burton Radons <burton-radons smocky.com> writes:
Walter Bright wrote:
 Jarrett Billingsley wrote:
 It turns out that static opCall() and this() are equivalent. C++ has 
 some obscure rules to try to disambiguate them. I wished to avoid 
 that problem, and since static opCall() is routinely in use, picked 
 them.

even if static opCalls are routinely in use, are they the best solution?

I've found they work well.

Do you have a single instance of a static opCall being used for construction where you don't just create a variable on the stack, build it, and return it? Because that's all I've ever done. Hundreds of times. Nothing else, and it just ends up being useless fluff making code harder to read than it should be. The opposite end of this would be so easy - if classes didn't have constructors. They don't actually need them after all - you just need to have the ability to create a blank instance. But can you see how much of a pointless pain in the ass that would be? That's exactly how it is in structs right now.
 And I also can't figure out how to make the implicit opCall work 
 with more than one parameter.  :P


Oh. I was thinking more along the lines of being able to do "S s(1, 2, 3);".

I prefer: auto s = S(1,2,3); to C++ style. static opCall fits right in.

Yeah, I've never liked C++'s handling of this, it looks way too much like a function call.
Dec 09 2006
parent Walter Bright <newshound digitalmars.com> writes:
Burton Radons wrote:
 Do you have a single instance of a static opCall being used for 
 construction where you don't just create a variable on the stack, build 
 it, and return it? Because that's all I've ever done. Hundreds of times. 
 Nothing else, and it just ends up being useless fluff making code harder 
 to read than it should be.

Given: auto s = S(1,2,3); I'm not sure what you mean?
Dec 09 2006
prev sibling next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:elfg41$139h$1 digitaldaemon.com...

 I've found they work well.

 And are they _really_ equivalent?

Not perfectly, but the differences are small.
 Where's the 'this' pointer in a static opCall()?

It's in your return value.

Okay, this obviously isn't working. Let's go at this from another angle. What is the TRUE reason you don't want to give structs ctors? I don't want to know why static opCalls are good, but why ctors are bad.
Dec 09 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Jarrett Billingsley wrote:
 What is the TRUE reason you don't want to give structs ctors?  I don't want 
 to know why static opCalls are good, but why ctors are bad. 

Constructor: S(v); static opCall: S(v) What's the difference? I just don't see the point for adding constructors.
Dec 09 2006
next sibling parent reply Burton Radons <burton-radons smocky.com> writes:
Walter Bright wrote:
 Jarrett Billingsley wrote:
 What is the TRUE reason you don't want to give structs ctors?  I don't 
 want to know why static opCalls are good, but why ctors are bad. 

Constructor: S(v); static opCall: S(v) What's the difference? I just don't see the point for adding constructors.

Here's the difference: struct S { this (int x) { w = calculate_something (x); } this (int x, int y) { this (x); z = calculate (y); } } struct S { static S opCall (int x) { S result; result.build (x); return result; } static S opCall (int x, int y) { S result; result.build (x, y); return result; } private void build (int x) { w = calculate (x); } private void build (int x, int y) { build (x); z = calculate (y); } } Look at all that waste! More than 50% of the code there is just restating things. This was much harder to write, is harder to maintain, and has granted us no benefits whatsoever.
Dec 09 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Burton Radons wrote:
 Here's the difference:
 
     struct S
     {
         this (int x)
         {
             w = calculate_something (x);
         }
 
         this (int x, int y)
         {
             this (x);
             z = calculate (y);
         }
     }

struct S { static S opCall(int x) { S result; result.w = calculate_something(x); return result; } static S opCall(int x, int y) { auto result = S(x); result.z = calculate(y); return result; } } It's 3 more lines of code. The two styles almost completely overlap, and since the latter is already in use, adding ctors just seems redundant.
Dec 09 2006
next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
Walter Bright wrote:

 Burton Radons wrote:
 Here's the difference:
 
     struct S
     {
         this (int x)
         {
             w = calculate_something (x);
         }
 
         this (int x, int y)
         {
             this (x);
             z = calculate (y);
         }
     }

struct S { static S opCall(int x) { S result; result.w = calculate_something(x); return result; } static S opCall(int x, int y) { auto result = S(x); result.z = calculate(y); return result; } } It's 3 more lines of code. The two styles almost completely overlap, and since the latter is already in use, adding ctors just seems redundant.

Struct can have opCall, which is why they were used as a workaround for ctors. This was almost ok, but creating language support (through statement rewriting) for a workaround sounds a very bad thing to add prior to 1.0. This is certainly controversial enough, to think over for more than 2 weeks. I personally agree with those who want struct ctors. -- Lars Ivar Igesund blog at http://larsivi.net DSource & #D: larsivi
Dec 10 2006
prev sibling parent Chad J <gamerChad _spamIsBad_gmail.com> writes:
Walter Bright wrote:
 Burton Radons wrote:
 
 Here's the difference:

     struct S
     {
         this (int x)
         {
             w = calculate_something (x);
         }

         this (int x, int y)
         {
             this (x);
             z = calculate (y);
         }
     }

struct S { static S opCall(int x) { S result; result.w = calculate_something(x); return result; } static S opCall(int x, int y) { auto result = S(x); result.z = calculate(y); return result; } } It's 3 more lines of code. The two styles almost completely overlap, and since the latter is already in use, adding ctors just seems redundant.

OK here are the things that make me want constructors instead of static opCall: It takes a lot longer to type. You say only 3 more lines, but in that example 9 lines of constructor code becomes 12 lines of opCall code. The resulting code that is specific to these features is 25% fluff, and that includes the trivial curly braces. Character wise it is worse. The typing doesn't bug me as much as this though: what if the struct's name changes? And what if the opCall is heavily overloaded when the name changes? It's more unneeded code refactoring. That is one reason D constructors are so cool, and it kinda sucks that structs don't have that too. Also, static opCall is almost always used in the same way as a constructor. I'd expect them to have the same syntax, but they don't. I think this, and some of the above reaons, result in the workaround perception - everyone expects the smooth 'this' syntax, but get static opCall instead. Now I read that you would like to keep the semantic differences intact because they are useful. Forcing the possibility of a bitwise copy of the struct before it is unleashed will apparently allow for cool stuff. I don't think it's too unreasonable to have the 'this' identifier be a value rather than a reference in a struct constructor. Thus you have a function that implicitly creates a blank instance of the struct, then allows the programmer to modify it via 'this', and implicitly returns the 'this' struct as static opCall would.
Dec 11 2006
prev sibling next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:elfreq$1dvs$1 digitaldaemon.com...
 Constructor:

 S(v);

 static opCall:

 S(v)

 What's the difference? I just don't see the point for adding constructors.

In addition to what Burton posted, class: class C { this() { } } Struct: struct S { static S opCall() { S s; return s; } } It's completely un-orthogonal. Wouldn't it be so much cleaner and make so much more sense to allow ctors for structs? Isn't this the _purpose_ of ctors, to initialize members to useful values? Why have static opCall mean something completely different for structs and classes?
Dec 09 2006
prev sibling next sibling parent reply Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Walter Bright wrote:
 Jarrett Billingsley wrote:
 What is the TRUE reason you don't want to give structs ctors?  I don't 
 want to know why static opCalls are good, but why ctors are bad. 

Constructor: S(v); static opCall: S(v) What's the difference? I just don't see the point for adding constructors.

The difference is that a ctor initializes an already-existing instance, while static opCall returns one, which is then copied. A static opCall won't handle the following case: ---- void delegate() globalDG; struct Foo { void func() { printf("myVal = %d\n", myVal); } static Foo opCall(int v) { Foo res; res.myVal = v; globalDG = &res.func; return res; } int myVal; } void main() { Foo f = Foo(5); globalDG(); // prints garbage instead of '5' } ---- The Foo instance returned from static opCall is copied, thus the 'ctor hack' doesn't have real access to the object it's constructing, not to mention the overhead of copying the struct to another place on stack... Also, new Foo(5) isn't going to work without real ctors or more hacks. -- Tomasz Stachowiak
Dec 09 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Tom S wrote:
 A static opCall 
 won't handle the following case:
 
 ----
 
 void delegate() globalDG;
 
 
 struct Foo {
     void func() {
         printf("myVal = %d\n", myVal);
     }
 
     static Foo opCall(int v) {
         Foo res;
         res.myVal = v;
         globalDG = &res.func;
         return res;
     }
 
     int myVal;
 }
 
 
 void main() {
     Foo f = Foo(5);
     globalDG();  // prints garbage instead of '5'
 }
 
 ----

Ok, you're right on that one. But I am going to argue on philosophical grounds that this kind of code is incorrect for a couple of reasons: 1) constructors should construct objects, not set state outside themselves. 2) trying to keep track of every struct created is going to put a hole below the waterline in some new capabilities planned for the future. The compiler needs to be able to willy-nilly create bit copies of structs for this to work. C++ has this problem in spades (just follow the skin-rending and hair-pulling going on with the "move constructor" issues). Allowing the compiler to be able to create bit copied temporaries without needing to call constructors is going to be worthwhile by enabling some pretty cool stuff. I'm going to put forward the idea that this kind of thing should be done with classes, not structs.
 The Foo instance returned from static opCall is copied, thus the 'ctor 
 hack' doesn't have real access to the object it's constructing, not to 
 mention the overhead of copying the struct to another place on stack...

It's time to put the recurring efficiency argument to bed. Consider this D code: ------------------- struct S { static S opCall(int v) { S result; result.v = v; return result; } int v; } int test() { auto s = S(5); return s.v; } ------------compiles to---------- _D4test1S6opCallFiZS4test1S comdat ret _D4test4testFZi comdat mov EAX,5 ret --------------------------------- It doesn't get any better than that.
 Also,  new Foo(5)  isn't going to work without real ctors or more hacks.

That can be supported without any more work than supporting it with ctors.
Dec 09 2006
next sibling parent reply Don Clugston <dac nospam.com.au> writes:
Walter Bright wrote:
 2) trying to keep track of every struct created is going to put a hole 
 below the waterline in some new capabilities planned for the future. The 
 compiler needs to be able to willy-nilly create bit copies of structs 
 for this to work. C++ has this problem in spades (just follow the 
 skin-rending and hair-pulling going on with the "move constructor" 
 issues). Allowing the compiler to be able to create bit copied 
 temporaries without needing to call constructors is going to be 
 worthwhile by enabling some pretty cool stuff.

Intriguing. Evidently the ideas barrel is far from empty. <g>
Dec 10 2006
parent Walter Bright <newshound digitalmars.com> writes:
Don Clugston wrote:
 Intriguing. Evidently the ideas barrel is far from empty. <g>

No chance of that happening <g>.
Dec 13 2006
prev sibling next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Walter Bright wrote:
 It's time to put the recurring efficiency argument to bed. Consider this 
 D code:

That is a relief to know. What about heap construction? I think currently with the opCall approach you have to do something like: auto x = new Struct; *x = Struct(args); Does that copy get optimized away too? There are other issues people are concerned about also. Maybe it does only take two extra lines to define a static opCall vs a constructor, but that extra two lines is basically redundant noise and makes static opCall look hackish. And given that most every struct is going to need a constructor, it is hackish noise that we're all going to have to (and already do) see a lot. Also the name "static opCall" doesn't exactly scream out "i'm a constructor". And there's no guarantee that if I'm given a random struct I'll be able to use StructName() as a constructor. Users are free to do whatever they want with static opCall. With a constructor you have to construct. Just like you said "constructors should construct objects" -- ok, but static opCall is not intrinsically a constructor, any more than a function called make() is a constructor. It might be used as a constructor, or it might not. There's also the consistency issue, that if construction is done with 'this()' for classes it should be done with 'this()' for structs. I can kind of see why you don't want to use this() because in classes that's triggered by using the 'new' keyword, and for stack construct structs it makes sense to not use 'new'. But then if structs can be value constructed with x = Struct(), then why not classes too? But classes have to be value constructed using 'scope'. Ok, what if you just sidestep all that and introduce something like opCreate for structs. Basically this would be identical to the current "static opCall", but you could write the code for it just like a constructor. Like so: opCreate(int arg) { m_member = arg; } I.e. you don't specify return type, return value, or 'static' etc. It works just like a constructor, but you call it like static opCall. auto x = MyStruct() It would be an error to have both a static opCall and an opCreate. Of course at that point it really raises the question "why not just call it 'this' instead of opCreate". And declare that for structs you can invoke 'this' by using x = MyStruct(). Anyway, I really don't see why it has to be an either/or situation. Let people use this/opCreate for new code, and let them continue to use static opCall in old code. But make it an error to have both in a struct. What's so hard about that? --bb
Dec 10 2006
parent reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Bill Baxter wrote:
 There's also the consistency issue, that if construction is done with 
 'this()' for classes it should be done with 'this()' for structs.
 

One issue I have with allowing struct constructors is that the existence of struct constructors implies the existence of struct destructors. Do we really want to go that far? Though "static opCall" doesn't scream "constructor," it also doesn't seem to imply the user could define a destructor. I submit that "this()" would. -- Kirk McDonald Pyd: Wrapping Python with D http://pyd.dsource.org
Dec 10 2006
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Kirk McDonald wrote:
 Bill Baxter wrote:
 There's also the consistency issue, that if construction is done with 
 'this()' for classes it should be done with 'this()' for structs.

One issue I have with allowing struct constructors is that the existence of struct constructors implies the existence of struct destructors. Do we really want to go that far? Though "static opCall" doesn't scream "constructor," it also doesn't seem to imply the user could define a destructor. I submit that "this()" would.

That seems like a non-issue to me. Even if people do take that to mean you can have a destructor, the compiler will crush any such delusions the moment you try to compile a struct with ~this in it. The compiler error message could even be "Structs cannot have destructors, only classes can". That should be pretty clear. Structs and classes are different in D. That's a fact, and new users are going to have to deal with it sooner or later. Should the language emphasize the similarities or stress the differences? I don't think it makes a big difference in this case. What's more important I think is that core operations can be performed in a way that is clear and unambiguous. No matter how you slice it, construction is a very common operation, and 'static opCall' does not offer a clear syntax for construction behavior, nor is it unambiguous in the sense that it can be used for any purpose the user desires. The fact that everyone was convinced that it must be inefficient because it *looks* like it's going to do extra copies is just another side effect of it using unambiguous constructor-like syntax. Walter went out of his way to avoid "looking hackish" with regard to foreach loops. It seems very odd to just accept hackish-looking constructors for structs. --bb
Dec 10 2006
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Bill Baxter wrote:

edit:
 The fact that everyone was convinced that it must be inefficient because it 
 *looks* like it's going to do extra copies is just another side effect 
 of it using unambiguous constructor-like syntax.

I mean "a side effect of it *not* using unambiguous constructor-like syntax", of course. --bb
Dec 10 2006
prev sibling next sibling parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Kirk McDonald wrote:
 Bill Baxter wrote:
 
 There's also the consistency issue, that if construction is done with 
 'this()' for classes it should be done with 'this()' for structs.

One issue I have with allowing struct constructors is that the existence of struct constructors implies the existence of struct destructors. Do we really want to go that far? Though "static opCall" doesn't scream "constructor," it also doesn't seem to imply the user could define a destructor. I submit that "this()" would.

Who knows, maybe D will have destructors for structs one day :o). Andrei
Dec 10 2006
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Andrei Alexandrescu (See Website For Email)" 
<SeeWebsiteForEmail erdani.org> wrote in message 
news:elihab$1q98$1 digitaldaemon.com...

 Who knows, maybe D will have destructors for structs one day :o).

 Andrei

I can see it now: DMD 0.178 * Added destructors for structs. Big thanks to Andrei.
Dec 10 2006
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:eliilm$1sk3$1 digitaldaemon.com...

 I can see it now:

 DMD 0.178
 * Added destructors for structs.  Big thanks to Andrei.

You can't see it, but there's a ";)" at the end of that post.
Dec 10 2006
prev sibling parent Boris Kolar <boris.kolar globera.com> writes:
== Quote from Kirk McDonald (kirklin.mcdonald gmail.com)'s article
 Bill Baxter wrote:
 One issue I have with allowing struct constructors is that the existence
 of struct constructors implies the existence of struct destructors. Do
 we really want to go that far?

I certainly do :) Since struct types are always known at compile-time, structs without destructors should not be affected. I think struct destructors will be very useful (RIAA, custom allocation/deallocation strategies).
Dec 11 2006
prev sibling parent reply BCS <BCS pathlink.com> writes:
Walter Bright wrote:
 Tom S wrote:
 The Foo instance returned from static opCall is copied, thus the 'ctor 
 hack' doesn't have real access to the object it's constructing, not to 
 mention the overhead of copying the struct to another place on stack...

It's time to put the recurring efficiency argument to bed. Consider this D code:

In many cases, it may be vary good. However consider the case where there is more than one return statement using different variables. You now need a much better optimizer to get this optimized down to "almost nothing". Furthermore, it doesn't reflect what is actually being done. struct S { static S err; int k, l; static S opCall(int i, int j) { S ret; ret.k=i; ret.l=j; if(ret.test) return ret; else ret err; } bool test(){...} } With constructors, it is not only simpler code, but looks like what is happening. struct S { static S err; int k, l; this(int i, int j) { k=i; l=j; if(!ret.test) this = err; } bool test(){...} }
Dec 11 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
BCS wrote:
 With constructors, it is not only simpler code, but looks like what is 
 happening.
 
 struct S
 {
     static S err;
     int k, l;
 
     this(int i, int j)
     {
         k=i;
         l=j;
 
         if(!ret.test) this = err;
     }
 
     bool test(){...}
 }

Assignment to this inside a constructor is a mistake as it breaks the assumptions the language makes about constructors.
Dec 13 2006
parent reply BCS <BCS pathlink.com> writes:
Walter Bright wrote:
 BCS wrote:
 
 With constructors, it is not only simpler code, but looks like what is 
 happening.

 struct S
 {
     static S err;
     int k, l;

     this(int i, int j)
     {
         k=i;
         l=j;

         if(!ret.test) this = err;
     }

     bool test(){...}
 }

Assignment to this inside a constructor is a mistake as it breaks the assumptions the language makes about constructors.

What assumptions does it break? This would be valid: struct S { static S err; int k, l; this(int i, int j) { k=i; l=j; if(!ret.test) { this.k = err.k; this.l = err.l; } } bool test(){...} } and as far as I can tell, they are the same. OK well maybe it should have been written as this: if(!ret.test) *this = err; // ^- add this Either way, I think the original argument still holds. The constructor form still looks more like what is acutely happening, and as a result has less of a "phantom" cost.
Dec 13 2006
parent Walter Bright <newshound digitalmars.com> writes:
BCS wrote:
 OK well maybe it should have been written as this:
 
         if(!ret.test) *this = err;
                    // ^- add this

That's completely different <g>.
 Either way, I think the original argument still holds. The constructor 
 form still looks more like what is acutely happening, and as a result 
 has less of a "phantom" cost.

Dec 14 2006
prev sibling parent Tom <ihate spam.com> writes:
Walter Bright escribiů:
 Jarrett Billingsley wrote:
 What is the TRUE reason you don't want to give structs ctors?  I don't 
 want to know why static opCalls are good, but why ctors are bad. 

Constructor: S(v); static opCall: S(v) What's the difference? I just don't see the point for adding constructors.

I don't understand: the current way to go (opCall) *is a workaround*. That means, it's frequently used by D programmers to simulate something that is missing in the language (at least in my case). What about elegance (one of the most beloved properties of D)? Doesn't it account at all? Regards, -- Tom;
Dec 10 2006
prev sibling parent Boris Kolar <boris.kolar globera.com> writes:
== Quote from Walter Bright (newshound digitalmars.com)'s article
 Jarrett Billingsley wrote:
 It turns out that static opCall() and this() are equivalent. C++ has some
 obscure rules to try to disambiguate them. I wished to avoid that problem,
 and since static opCall() is routinely in use, picked them.

static opCalls are routinely in use, are they the best solution?


Yes, but ctors would work even better: this(int a, int b) { _a = a; _b = b; } static Foo opCall(int a, int b) { Foo foo; foo._a = a; foo._b = b; return foo; } Suggestion: disallow both opCall and ctor for the same struct and there should be no ambiguity issues.
 That's implicit casting from a struct. It'll probably wind up getting
 supported in one form or another.

That's great :) It seems that some D issues suffer from "Black hole theory of languages": "C++ is a Black Hole: if you try to design something that's not C++, but like C++, you'll find that the gravitational forces on the design will suck it into the Black Hole, and it will become C++"
Dec 10 2006
prev sibling next sibling parent Marcin Kuszczak <aarti interia.pl> writes:
Walter Bright wrote:

 I'm also a little wary about opAssign.  Not that I don't find it useful,
 just that you've been vehemently opposed to overloading it in D for how
 many years, and three weeks before 1.0 you reverse your opinion.  What
 does that mean?

The problem I have, and still have, is the identity assignment. This is specifically disallowed with opAssign. I can go into the reasons why if you like.

I wonder if it is not possible to make D, working as a base with values not with references. In such a case references would be hidden from programmers and only values would be visible at first. Assigning would always mean assign value, and when there should be passed reference the special syntax would be necessary, so references would be special case. To disambiguate you can make something like this: auto v := new Any; // special assignment operator ':=' for references auto z := new Any; v = 5; // Standard opAssign z = v; // No problem here, opAssign can be used as usually z :=v; // Reference copy - opAssign is not used here Additionally when passing arguments to function, which demands references, there could be used implicit conversion from values to references (so that for user it would be visible as sending values). Below example almost works now (almost because constructors can not be templatized): void varFunc(Any[] arr ...) {         foreach(v; arr) writefln(v.type); } void main() { #       varFunc(new Any(5), new Any("tekst"[]), new Any(&variadicFunction)); } In language in which everything is consider as an object you could just write: void main() { bool test; # varFunc(Any(5), Any("tekst"[]), Any(&variadicFunction)); # varFunc(Any(5.6), Any(&test)); } If there should be send reference(pointer) it should be done explicitly. E.g. void varFunc(Any*[] arr ...) { .... } void main() { # varFunc(new Any(5), new Any("tekst"[]), new Any(&variadicFunction)); } Does it make any sense? Please comment...
 Having opAssign for foreign types turns out to be needed for things
 like, say I want to build a ranged integer. This is an integer that can
 only have values between m and n. Without opAssign, I'd have to use a
 property:
 RangedInt!(m,n) r;
 r.value = 6;
 It's just not right.

the same in case of boost::Any port to D. -- Regards Marcin Kuszczak (Aarti_pl)
Dec 09 2006
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
Brad Roberts wrote:
 
 Since the desired behavior is construction, let's stop kidding ourselves 
 and actually give structs both the behavior and the syntax of 
 construction, please?  And while you're in there.. how about destruction 
 and RAII?

What ever happened to structs as aggregates? I thought this was their entire purpose for being in D. Adding ctors makes sense because it merely simplifies initialization, but adding dtors, copy semantics, and opAssign all seem bent on making structs into something they're not. After all, isn't that why we have classes? In fact, many of the instances where I was inclined to use structs simply to avoid the GC evaporated when stack construction of classes was added a few releases ago. Aside from the addition of a ctor, I'm quite happy to leave structs exactly as they were before 177. That said, I suppose I can appreciate the desire to give classes opAssign (even though it's somewhat weird), and perhaps the operator was added to structs simply for the sake of consistency. Sean
Dec 11 2006
next sibling parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Sean Kelly wrote:
 Brad Roberts wrote:
 
 Since the desired behavior is construction, let's stop kidding 
 ourselves and actually give structs both the behavior and the syntax 
 of construction, please?  And while you're in there.. how about 
 destruction and RAII?

What ever happened to structs as aggregates? I thought this was their entire purpose for being in D. Adding ctors makes sense because it merely simplifies initialization, but adding dtors, copy semantics, and opAssign all seem bent on making structs into something they're not. After all, isn't that why we have classes? In fact, many of the instances where I was inclined to use structs simply to avoid the GC evaporated when stack construction of classes was added a few releases ago. Aside from the addition of a ctor, I'm quite happy to leave structs exactly as they were before 177. That said, I suppose I can appreciate the desire to give classes opAssign (even though it's somewhat weird), and perhaps the operator was added to structs simply for the sake of consistency.

Classes are different from structs in two essential ways: 1. Polymorphism 2. Referential semantics The two are actually interdependent, as you can't have polymorphism comfortably unless you have reference semantics. That's the important distinction. Other than that, it's good that they share a number of valuable properties. Take private state for example. structs as sheer unchecked aggregates would provide too little value to be useful. Most of the time, aggregating some state together (date, time, etc.) comes together with some desirable invariant that the aggregate should hold, meaning that not all possible bit patterns of the aggregate can be meaningful. So it's useful that struct has private state. Consequently, they should have member functions (setters, getters) and the such. They also should have constructors so they can put themselves in a meaningful initial state, and should have opAssign so they allow controlled overwriting of their state. (It's an accident that opAssign from the same type has not been implemented yet; it can be safely allowed.) On the other hand, intercepting _duplication_ of structs naively would be a major breach in the object model, because it would frontally collide with (2) above: structs are values and the compiler can move and copy structs around discretionary using bitwise copying. That's why D currently does not allow interception of copy construction and destruction. It might in the future, but in a way that does not clash with the object model. (That is doable.) So my point was, as attractive the simple mantra "structs should be aggregates" is, it turns out it's not that useful. So it's great that D supports efficient and safe user-defined values. Andrei
Dec 11 2006
next sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Andrei Alexandrescu (See Website For Email) wrote:
 Sean Kelly wrote:
 Brad Roberts wrote:

 Since the desired behavior is construction, let's stop kidding 
 ourselves and actually give structs both the behavior and the syntax 
 of construction, please?  And while you're in there.. how about 
 destruction and RAII?

What ever happened to structs as aggregates? I thought this was their entire purpose for being in D. Adding ctors makes sense because it merely simplifies initialization, but adding dtors, copy semantics, and opAssign all seem bent on making structs into something they're not. After all, isn't that why we have classes? In fact, many of the instances where I was inclined to use structs simply to avoid the GC evaporated when stack construction of classes was added a few releases ago. Aside from the addition of a ctor, I'm quite happy to leave structs exactly as they were before 177. That said, I suppose I can appreciate the desire to give classes opAssign (even though it's somewhat weird), and perhaps the operator was added to structs simply for the sake of consistency.

Classes are different from structs in two essential ways: 1. Polymorphism 2. Referential semantics The two are actually interdependent, as you can't have polymorphism comfortably unless you have reference semantics. That's the important distinction. Other than that, it's good that they share a number of valuable properties. Take private state for example. structs as sheer unchecked aggregates would provide too little value to be useful. Most of the time, aggregating some state together (date, time, etc.) comes together with some desirable invariant that the aggregate should hold, meaning that not all possible bit patterns of the aggregate can be meaningful. So it's useful that struct has private state. Consequently, they should have member functions (setters, getters) and the such. They also should have constructors so they can put themselves in a meaningful initial state, and should have opAssign so they allow controlled overwriting of their state. (It's an accident that opAssign from the same type has not been implemented yet; it can be safely allowed.)

"allow controlled overwriting of their state" -> Would that be for the case where the struct's private state (aka abstract state) is not just the bit pattern value of the struct, but also the contents of pointer/reference members? -- Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Dec 11 2006
parent reply "Andrei Alexandrescu (See Website for Email)" <SeeWebsiteForEmail erdani.org> writes:
Bruno Medeiros wrote:
 "allow controlled overwriting of their state" -> Would that be for the 
 case where the struct's private state (aka abstract state) is not just 
 the bit pattern value of the struct, but also the contents of 
 pointer/reference members?

That too. The canonical example is simpler - reject invalid attempts at setting state. Consider: struct BoundedInt(int min, int max) { ... } alias BoundedInt!(0, 100) Percent; Percent soFar = 0; ... soFar = bytesCopied * 100 / bytesToCopy; Upon assignment, the bounded int structure should do a runtime check to make sure it is being set to a number within bounds. Andrei
Dec 11 2006
parent Felix T <noemail noemail.com> writes:
To Andrei Alexandrescu:

 - Voiam doar sa salut prezenta dvs aici.
 - I greet your presence here.
Dec 11 2006
prev sibling next sibling parent Sean Kelly <sean f4.ca> writes:
Andrei Alexandrescu (See Website For Email) wrote:
 
 Classes are different from structs in two essential ways:
 
 1. Polymorphism
 2. Referential semantics
 
 The two are actually interdependent, as you can't have polymorphism
 comfortably unless you have reference semantics.

Certainly.
 That's the important distinction. Other than that, it's good that they
 share a number of valuable properties. Take private state for example.
 structs as sheer unchecked aggregates would provide too little value to
 be useful. Most of the time, aggregating some state together (date,
 time, etc.) comes together with some desirable invariant that the 
 aggregate should hold, meaning that not all possible bit patterns of the 
 aggregate can be meaningful. So it's useful that struct has private 
 state. Consequently, they should have member functions (setters, 
 getters) and the such. They also should have constructors so they can 
 put themselves in a meaningful initial state, and should have opAssign 
 so they allow controlled overwriting of their state. (It's an accident 
 that opAssign from the same type has not been implemented yet; it can be 
 safely allowed.)

Point made. And I suppose opAssign isn't truly linked to the idea of object copy semantics--I've just gotten used to associating the two because of my experience with C++.
 So my point was, as attractive the simple mantra "structs should be
 aggregates" is, it turns out it's not that useful. So it's great that D
 supports efficient and safe user-defined values.

structs as aggregates do come in quite handy for a few specific situations, but I agree that they aren't tremendously useful in the general sense. It's beginning to seem, then, that common value types in D will be represented as structs, with classes reserved for those types with copy requirements. Once implicit cast support is added, it seems we'll be in pretty good shape for UDTs in D. And here I'd come to accept that we'd never have them :-) Sean
Dec 11 2006
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:
 Classes are different from structs in two essential ways:
 
 1. Polymorphism
 2. Referential semantics
 
 The two are actually interdependent, as you can't have polymorphism
 comfortably unless you have reference semantics.

That's one of the things I felt in my bones, but was unable to put my finger on it.
Dec 12 2006
next sibling parent reply Boris Kolar <boris.kolar globera.com> writes:
== Quote from Walter Bright (newshound digitalmars.com)'s article
 Andrei Alexandrescu (See Website For Email) wrote:
 Classes are different from structs in two essential ways:

 1. Polymorphism
 2. Referential semantics

 The two are actually interdependent, as you can't have polymorphism
 comfortably unless you have reference semantics.

finger on it.

Actually, polymorphism does not imply referential semantics (nor does referential semantics imply polymorphism, of course). 1) Value sematics can be achieved with references as well, by using copy-on-write strategy (or by making classes immutable). All that without sacrificing polymorphism. 2) Polymorphism can be achieved without references as well, but then the size of struct could no longer be determined at comile-time. In other words, function 'sizeof' could no longer be parameterless. Or, alternatively, every such 'polymorphic struct' would have to contain two pointers: VMT and additional 'data' pointer (which is actually pretty close to using references anyway). I'm in favour of allowing programmer to mark special semantics, such as value class, or pure function (without side effects). Many additional optimizations can be performed under such assumptions. Most notably: value classes could be destroyed predictably (without causing arbitrary long GC pauses) and calls to pure functions with unchanged parameters can be cached (for example, foo.name().length()...). Also, it would be interesting to mark some functions as compile-time, requiring that they only interact with values that are known in compile-time. This would make metaprogramming much more similar to normal programming. One additional nice thing: you can support such declarations even before optimizer takes advantage of them. Also, I would suggest issuing a compile-time warning when polymorphism is used without explicit 'override' directive. Perhaps coupled with a pragma or something to turn such warning off. PS: I really appreciate all the work that has been put in D. D is going to be a much needed successor of C++. I don't see D as competitor to Java or C# (I think that when using .NET or JVM is an option, D would be a terrible choice), but it sure can rock the non-VM world!
Dec 12 2006
next sibling parent reply Ivan Senji <ivan.senji gmail.com> writes:
Boris Kolar wrote:
 PS: I really appreciate all the work that has been put in D. D is going
 to be a much needed successor of C++. I don't see D as competitor to
 Java or C# (I think that when using .NET or JVM is an option, D would
 be a terrible choice), but it sure can rock the non-VM world!

Why not? I think that D could rock the .NET world too. I always wished (and still do) for a d.net implementation.
Dec 12 2006
parent reply Alexander Panek <a.panek brainsware.org> writes:
Ivan Senji wrote:
 Boris Kolar wrote:
 PS: I really appreciate all the work that has been put in D. D is going
 to be a much needed successor of C++. I don't see D as competitor to
 Java or C# (I think that when using .NET or JVM is an option, D would
 be a terrible choice), but it sure can rock the non-VM world!

Why not? I think that D could rock the .NET world too. I always wished (and still do) for a d.net implementation.

.NET is not the solution for all problems. There will be other library approaches that maybe even perform better and use features of D that make it like .NET on steroids. I bet after some time of an official, fixed D 1.0 specification, there will some libraries pop up that may serve needs like .NET or J2EE and what not do, also. Apart from that.. hey, you're posting this in the official D newsgroup ;) . Kind regards, Alex
Dec 12 2006
parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Alexander Panek wrote:
 Ivan Senji wrote:
 Boris Kolar wrote:
 PS: I really appreciate all the work that has been put in D. D is going
 to be a much needed successor of C++. I don't see D as competitor to
 Java or C# (I think that when using .NET or JVM is an option, D would
 be a terrible choice), but it sure can rock the non-VM world!

Why not? I think that D could rock the .NET world too. I always wished (and still do) for a d.net implementation.

..NET is not the solution for all problems.

Naturally. That is why we are here (using D).
 There will be other library 
 approaches that maybe even perform better and use features of D that 
 make it like .NET on steroids. I bet after some time of an official, 
 fixed D 1.0 specification, there will some libraries pop up that may 
 serve needs like .NET or J2EE and what not do, also.

I sure hope so. What I was trying to say programming in .NET is sometimes required and in those cases i would prefer D rather than C# or (even worse) VB.
 
 Apart from that.. hey, you're posting this in the official D newsgroup ;) .

Is that a problem? :)
Dec 12 2006
parent reply Alexander Panek <a.panek brainsware.org> writes:
Ivan Senji wrote:
 Alexander Panek wrote:
 Ivan Senji wrote:
 Boris Kolar wrote:
 PS: I really appreciate all the work that has been put in D. D is going
 to be a much needed successor of C++. I don't see D as competitor to
 Java or C# (I think that when using .NET or JVM is an option, D would
 be a terrible choice), but it sure can rock the non-VM world!

Why not? I think that D could rock the .NET world too. I always wished (and still do) for a d.net implementation.

..NET is not the solution for all problems.

Naturally. That is why we are here (using D).

Exacteley!
 
 There will be other library approaches that maybe even perform better 
 and use features of D that make it like .NET on steroids. I bet after 
 some time of an official, fixed D 1.0 specification, there will some 
 libraries pop up that may serve needs like .NET or J2EE and what not 
 do, also.

I sure hope so. What I was trying to say programming in .NET is sometimes required and in those cases i would prefer D rather than C# or (even worse) VB.

Are you, actually, talking about a D -> MSIL compiler, so it can be run inside the VM and a .NET implementation in D, for that purpose? Or do you mean something /similar/ to C# + .NET? If so, I agree. Something like that has to be in D. :) I hope this will pop up
 Apart from that.. hey, you're posting this in the official D newsgroup 
 ;) .

Is that a problem? :)

Of course not. Was just a side-kick regarding your "I want .NET in D" statement :) . Kind regards, Alex
Dec 12 2006
next sibling parent Ivan Senji <ivan.senji gmail.com> writes:
Alexander Panek wrote:
 Ivan Senji wrote:
 I sure hope so.
 What I was trying to say programming in .NET is sometimes required and
 in those cases i would prefer D rather than C# or (even worse) VB.

Are you, actually, talking about a D -> MSIL compiler, so it can be run inside the VM and a .NET implementation in D, for that purpose? Or do you mean something /similar/ to C# + .NET? If so, I agree. Something like that has to be in D. :) I hope this will pop up

Actually I really was talking about a D->MSIL compiler for those cases when you just have to use .net and would still prefer other benefits of D. But the other thing would be great too.
 
 Apart from that.. hey, you're posting this in the official D
 newsgroup ;) .

Is that a problem? :)

Of course not. Was just a side-kick regarding your "I want .NET in D" statement :) .

:P
Dec 12 2006
prev sibling parent reply "Lionello Lunesu" <lionello lunesu.remove.com> writes:
"Alexander Panek" <a.panek brainsware.org> wrote in message 
news:eln5td$2pta$1 digitaldaemon.com...
 Are you, actually, talking about a D -> MSIL compiler, so it can be run 
 inside the VM and a .NET implementation in D, for that purpose? Or do you 
 mean something /similar/ to C# + .NET? If so, I agree. Something like that 
 has to be in D. :) I hope this will pop up

We had one, once : ( but then the guy's HDD crashed... Sad, sad story. L.
Dec 13 2006
parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Lionello Lunesu wrote:
 "Alexander Panek" <a.panek brainsware.org> wrote in message 
 news:eln5td$2pta$1 digitaldaemon.com...
 Are you, actually, talking about a D -> MSIL compiler, so it can be run 
 inside the VM and a .NET implementation in D, for that purpose? Or do you 
 mean something /similar/ to C# + .NET? If so, I agree. Something like that 
 has to be in D. :) I hope this will pop up

We had one, once : ( but then the guy's HDD crashed... Sad, sad story. L.

https://mywebspace.wisc.edu/daaugustine/web/d/ This is all that remains of all his work, so far as I can tell. Some day it would be nice if http://www.scratch-ware.net/dfiles/ suddenly existed again. Oh well. -- Chris Nicholson-Sauls
Dec 14 2006
parent reply Justin C Calvarese <technocrat7 gmail.com> writes:
Chris Nicholson-Sauls wrote:
 Lionello Lunesu wrote:
 "Alexander Panek" <a.panek brainsware.org> wrote in message 
 news:eln5td$2pta$1 digitaldaemon.com...
 Are you, actually, talking about a D -> MSIL compiler, so it can be 
 run inside the VM and a .NET implementation in D, for that purpose? 
 Or do you mean something /similar/ to C# + .NET? If so, I agree. 
 Something like that has to be in D. :) I hope this will pop up

We had one, once : ( but then the guy's HDD crashed... Sad, sad story. L.

https://mywebspace.wisc.edu/daaugustine/web/d/ This is all that remains of all his work, so far as I can tell. Some day it would be nice if http://www.scratch-ware.net/dfiles/ suddenly existed again. Oh well. -- Chris Nicholson-Sauls

I think I have pretty much all of the binary files he released (though they're archived on some CD in my closet), but he never released any source before his hard drive crashed, so I don't have any of that. And I think the binaries targeted some beta version of .NET and required .dll's that you'd only have if you installed a beta version of Visual Studio. Seemed like a cool idea, but it took a lot of effort just to try it out... -- jcc7
Dec 14 2006
parent reply Lionello Lunesu <lio lunesu.remove.com> writes:
Justin C Calvarese wrote:
 Chris Nicholson-Sauls wrote:
 Lionello Lunesu wrote:
 "Alexander Panek" <a.panek brainsware.org> wrote in message 
 news:eln5td$2pta$1 digitaldaemon.com...
 Are you, actually, talking about a D -> MSIL compiler, so it can be 
 run inside the VM and a .NET implementation in D, for that purpose? 
 Or do you mean something /similar/ to C# + .NET? If so, I agree. 
 Something like that has to be in D. :) I hope this will pop up

We had one, once : ( but then the guy's HDD crashed... Sad, sad story. L.

https://mywebspace.wisc.edu/daaugustine/web/d/ This is all that remains of all his work, so far as I can tell. Some day it would be nice if http://www.scratch-ware.net/dfiles/ suddenly existed again. Oh well. -- Chris Nicholson-Sauls

I think I have pretty much all of the binary files he released (though they're archived on some CD in my closet), but he never released any source before his hard drive crashed, so I don't have any of that. And I think the binaries targeted some beta version of .NET and required .dll's that you'd only have if you installed a beta version of Visual Studio.

Can't assemblies be fairly easily disassembled? L.
Dec 15 2006
parent Sean Kelly <sean f4.ca> writes:
Lionello Lunesu wrote:
 Justin C Calvarese wrote:
 Chris Nicholson-Sauls wrote:
 Lionello Lunesu wrote:
 "Alexander Panek" <a.panek brainsware.org> wrote in message 
 news:eln5td$2pta$1 digitaldaemon.com...
 Are you, actually, talking about a D -> MSIL compiler, so it can be 
 run inside the VM and a .NET implementation in D, for that purpose? 
 Or do you mean something /similar/ to C# + .NET? If so, I agree. 
 Something like that has to be in D. :) I hope this will pop up

We had one, once : ( but then the guy's HDD crashed... Sad, sad story. L.

https://mywebspace.wisc.edu/daaugustine/web/d/ This is all that remains of all his work, so far as I can tell. Some day it would be nice if http://www.scratch-ware.net/dfiles/ suddenly existed again. Oh well. -- Chris Nicholson-Sauls

I think I have pretty much all of the binary files he released (though they're archived on some CD in my closet), but he never released any source before his hard drive crashed, so I don't have any of that. And I think the binaries targeted some beta version of .NET and required .dll's that you'd only have if you installed a beta version of Visual Studio.

Can't assemblies be fairly easily disassembled?

Yes. In fact, the times I've done it I've seen an exact copy of the original source code (!). Try Reflector from this link: http://www.aisto.com/roeder/dotnet/ Sean
Dec 15 2006
prev sibling parent "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Boris Kolar wrote:
 == Quote from Walter Bright (newshound digitalmars.com)'s article
 
Andrei Alexandrescu (See Website For Email) wrote:

Classes are different from structs in two essential ways:

1. Polymorphism
2. Referential semantics

The two are actually interdependent, as you can't have polymorphism
comfortably unless you have reference semantics.

That's one of the things I felt in my bones, but was unable to put my finger on it.

Actually, polymorphism does not imply referential semantics (nor does referential semantics imply polymorphism, of course). 1) Value sematics can be achieved with references as well, by using copy-on-write strategy (or by making classes immutable). All that without sacrificing polymorphism.

Of course. It's a "true but uninteresting" fact. Even in current D you can think that int is a reference and that ++i rebinds i to another value. But when talking about reference semantics, that means object is unique, references are many. Doing copy-on-write takes reference-ness out of references, so of course then they start behaving like value.
 2) Polymorphism can be achieved without references as well, but then
 the size of struct could no longer be determined at comile-time. In
 other words, function 'sizeof' could no longer be parameterless. Or,
 alternatively, every such 'polymorphic struct' would have to contain
 two pointers: VMT and additional 'data' pointer (which is actually
 pretty close to using references anyway).

Yup, that's reference all right. Some Java implementations do this. Andrei
Dec 12 2006
prev sibling parent "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:
 Andrei Alexandrescu (See Website For Email) wrote:
 
 Classes are different from structs in two essential ways:

 1. Polymorphism
 2. Referential semantics

 The two are actually interdependent, as you can't have polymorphism
 comfortably unless you have reference semantics.

That's one of the things I felt in my bones, but was unable to put my finger on it.

I feel it in my bones too. It hurts when it rains :o). Andrei
Dec 12 2006
prev sibling parent reply "John Reimer" <terminal.node gmail.com> writes:
On Mon, 11 Dec 2006 10:50:41 -0800, Sean Kelly <sean f4.ca> wrote:

 Brad Roberts wrote:
  Since the desired behavior is construction, let's stop kidding  =


 ourselves and actually give structs both the behavior and the syntax =


 construction, please?  And while you're in there.. how about  =


 destruction and RAII?

What ever happened to structs as aggregates? I thought this was their=

 entire purpose for being in D.  Adding ctors makes sense because it  =

 merely simplifies initialization, but adding dtors, copy semantics, an=

 opAssign all seem bent on making structs into something they're not.  =

 After all, isn't that why we have classes?  In fact, many of the  =

 instances where I was inclined to use structs simply to avoid the GC  =

 evaporated when stack construction of classes was added a few releases=

 ago.  Aside from the addition of a ctor, I'm quite happy to leave  =

 structs exactly as they were before 177.  That said, I suppose I can  =

 appreciate the desire to give classes opAssign (even though it's  =

 somewhat weird), and perhaps the operator was added to structs simply =

 for the sake of consistency.


 Sean

I used to be convinced that struct's needed constructors; but now I see = = that there is a steam-roll effect as the demand for one class-like = attribute is proposed: suddenly people want more class-related = functionality or people argue that there is a basis for additional = features for the sake of consistancy. Then the redesign of structs star= ts = taking on the appearance of a reegineered, specialized class -- somethin= g = of a "context switch" too since classes use reference semantics. Perhap= s = we should be careful about hurtling too far in the direction of C++? From the perspective of setting initial state, classes in the OOP conte= xt = use constructors to do that. Structs were never intended to have OOP li= ke = syntax (or so it seems to me). Why can't structs just use an initialize= r = like constants or statics? I notice that Walter has added the struct = initialization using S(x) syntax. I think it is somewhat strange, but I= = suppose that was designed to be an alternative to constructor = initialization? What happened to something like a struct literal = intializer (which only works for static structs and constant values)? W= hy = can't such initialization be extended to local structs? ... struct S { int i; bool b; } static S t =3D { 5, true }; // must be "static" or initialization won't= work ... The above only works for static Structs. But that kind of initializatio= n = seems to be more consistant with the imperitive style of structs verses = = the OOP style of classes (if only non-statics could be initialized too, = = that is). When all is said and done, this is just like doing the same as= = S( 5, 2 ) since 0.177. But I guess as soon as we start adding "methods" to the struct that are = = responsible for changing state in the struct, a whole new set of = principles comes to work. Adding constructor funtionality via "this()" = is = only one way to fix it. opCall, the current way, is a rather ugly = default. If it is important to keep structs distinct from classes, then= = structs need to adopt a alternate way of doing initialization (but pleas= e = not opCall). I don't think "this()" really is the optimal way, though = perhaps the most familiar due to the influence of classes. I think ther= e = should remain a strong distinction between class and struct. If, nevertheless, Walter decides to implement a "this" constructor for = struct, I really hope he doesn't feel the need to go with a destructor a= nd = more class-like functionality as well. Ironically, I feel more sympathetic to what appears to be Walter's opini= on = on the matter this time around. :D -JJR
Dec 11 2006
parent reply Sean Kelly <sean f4.ca> writes:
John Reimer wrote:
 
  From the perspective of setting initial state, classes in the OOP 
 context use constructors to do that.  Structs were never intended to 
 have OOP like syntax (or so it seems to me).  Why can't structs just use 
 an initializer like constants or statics?  I notice that Walter has 
 added the struct initialization using S(x) syntax.  I think it is 
 somewhat strange, but I suppose that was designed to be an alternative 
 to constructor initialization?   What happened to something like a 
 struct literal intializer (which only works for static structs and 
 constant values)?  Why can't such initialization be extended to local 
 structs?
 
 ....
 struct S
 {
    int i;
    bool b;
 }
 
 static S t = { 5, true };  // must be "static" or initialization won't work

I think the problem here is that such initializers would not apply to private data, and more to the point, a ctor can do more than simply assign a constant to each member of the struct. But it would be nice if this syntax worked for non-static structs anyway.
 But I guess as soon as we start adding "methods" to the struct that are 
 responsible for changing state in the struct, a whole new set of 
 principles comes to work.  Adding constructor funtionality via "this()" 
 is only one way to fix it.  opCall, the current way, is a rather ugly 
 default.  If it is important to keep structs distinct from classes, then 
 structs need to adopt a alternate way of doing initialization (but 
 please not opCall).  I don't think "this()" really is the optimal way, 
 though perhaps the most familiar due to the influence of classes.  I 
 think there should remain a strong distinction between class and struct.

As do I. And I suppose the presence or lack of polymorphism is a sufficient distinction--the underpinnings for polymorphism do have a fairly significant impact on how an object is represented internally, etc.
 If, nevertheless, Walter decides to implement a "this" constructor for 
 struct, I really hope he doesn't feel the need to go with a destructor 
 and more class-like functionality as well.

The idea of a dtor for structs doesn't make much sense to me because of the bit-copy semantics. When would the dtor for a struct used as a return value be called? Sean
Dec 11 2006
parent "John Reimer" <terminal.node gmail.com> writes:
On Mon, 11 Dec 2006 15:57:51 -0800, Sean Kelly <sean f4.ca> wrote:

 John Reimer wrote:
   From the perspective of setting initial state, classes in the OOP  =


 context use constructors to do that.  Structs were never intended to =


 have OOP like syntax (or so it seems to me).  Why can't structs just =


 use an initializer like constants or statics?  I notice that Walter h=


 added the struct initialization using S(x) syntax.  I think it is  =


 somewhat strange, but I suppose that was designed to be an alternativ=


 to constructor initialization?   What happened to something like a  =


 struct literal intializer (which only works for static structs and  =


 constant values)?  Why can't such initialization be extended to local=


 structs?
  ....
 struct S
 {
    int i;
    bool b;
 }
  static S t =3D { 5, true };  // must be "static" or initialization w=


 work

I think the problem here is that such initializers would not apply to =

 private data, and more to the point, a ctor can do more than simply  =

 assign a constant to each member of the struct.  But it would be nice =

 this syntax worked for non-static structs anyway.

Ah true. But then, maybe there shouldn't be private data in a struct = either. :) I still see structs as a fairly basic non-OOP entity. -JJR
Dec 11 2006
prev sibling parent Brad Roberts <braddr puremagic.com> writes:
Walter Bright wrote:
 Jarrett Billingsley wrote:
 No offense, but would it honestly kill you to allow ctors in structs?  
 We've been using static opCall as a _workaround_ for the lack of 
 struct ctors, and making it part of the language doesn't really seem 
 to be addressing the problem.  That, and it doesn't make any sense 
 that classes use "this()" and structs use "static S opCall()".  We're 
 starting to get into "overloading indexing in C++" territory.

It turns out that static opCall() and this() are equivalent. C++ has some obscure rules to try to disambiguate them. I wished to avoid that problem, and since static opCall() is routinely in use, picked them.

Just because someone at some time in the distant pass realized that opCall() simulates constructor-like behavior, it doesn't make it 'ok'; it makes it 'an ok work around'. Think back over the last year.. how many people have asked how to create a constructor for structs? How much you wanna bet none of them would have had to ask if 'this' wasn't misspelled as 'opCall'? Since the desired behavior is construction, let's stop kidding ourselves and actually give structs both the behavior and the syntax of construction, please? And while you're in there.. how about destruction and RAII? I guess I'm in the camp that would like to see structs be closer to classes but am ok with them not supporting inheritance and other features that lead to vtables. Later, Brad
Dec 09 2006
prev sibling next sibling parent Marcin Kuszczak <aarti interia.pl> writes:
Walter Bright wrote:

 More ABI changes, and implicit [] => * no longer allowed.
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.175.zip

opAssing not mentioned here, but anyway I like what I have read in Docs! Finally I can use more user friendly and compact syntax for assigning values to Any (http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D.announce&artnum=4827): auto v=new Any; Was: v.assign(5); Now: v=5; Very good syntax for this kind of container! I just miss templatized constructors and following will be available: void varFunc(Any[] arr ...) { foreach(v; arr) { writefln(v.type); } } void main() { bool test; # varFunc(new Any(5), new Any("tekst"[]), new Any(&variadicFunction)); # varFunc(new Any(5.6), new Any(&test)); } (Currently it is necessary to write: # varFunc((new Any).assign(5.6), (new Any).assign(&test)); ) I will send updated version of Any soon... -- Regards Marcin Kuszczak (Aarti_pl)
Dec 09 2006
prev sibling next sibling parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
Walter Bright wrote:
 More ABI changes, and implicit [] => * no longer allowed.
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.175.zip

# Casting a value v to a struct S is now rewritten as S(v). # Initializing a struct S from a value v is now rewritten as S(v). Can you clarify more what that means? # TypeInfo now always generated for enum, struct, and typedef's, to enable more thorough rtti. So, can we get a string version of enum values? and can we get struct names? # hidden feature? Why is everyone talking about opAssign? I don't see it mentioned in the change log.
Dec 09 2006
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Hasan Aljudy" <hasan.aljudy gmail.com> wrote in message 
news:elfcgr$v45$1 digitaldaemon.com...

 Why is everyone talking about opAssign? I don't see it mentioned in the 
 change log.

Have a look on the "Operator Overloading" page of the spec.
Dec 09 2006
prev sibling next sibling parent reply clayasaurus <clayasaurus gmail.com> writes:
Walter Bright wrote:
 More ABI changes, and implicit [] => * no longer allowed.
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.175.zip

I'm not sure if this is a bug or what, but to get derelict from not spitting out this error message... derelict\opengl\glu.obj(glu) Error 42: Symbol Undefined _D8derelict6opengl3glu8GLUnurbs6__initZ derelict\opengl\glu.obj(glu) Error 42: Symbol Undefined _D8derelict6opengl3glu10GLUquadric6__initZ derelict\opengl\glu.obj(glu) Error 42: Symbol Undefined _D8derelict6opengl3glu13GLUtesselator6__initZ In glu.d line 287-289 I had to change struct GLUnurbs; struct GLUquadric; struct GLUtesselator; to struct GLUnurbs{} struct GLUquadric{} struct GLUtesselator{} In order for the compiler to recognize the symbols. Thanks for the release. ~ Clay
Dec 09 2006
parent reply "Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> writes:
did you recompile linked D libs?
Dec 10 2006
parent clayasaurus <clayasaurus gmail.com> writes:
Frank Benoit (keinfarbton) wrote:
 did you recompile linked D libs?

Yes, I actually don't use any linked libs since D compiles so fast. I just let build pull in what it wants to.
Dec 10 2006
prev sibling next sibling parent reply "Lionello Lunesu" <lionello lunesu.remove.com> writes:
Walter, you forgot to change this line in the docs:

"The operators =, !, ., &&, ||, ?:, and a few others will likely never be 
overloadable. "
http://www.digitalmars.com/d/operatoroverloading.html

: )

L. 
Dec 10 2006
parent Walter Bright <newshound digitalmars.com> writes:
<g>
Dec 10 2006
prev sibling next sibling parent reply Samuel MV <samuel jxdesigner.com> writes:
Thank you, Walter.

D 1.0 is going to be THE BEST general purpose language ... :D
Dec 10 2006
parent Alexander Panek <a.panek brainsware.org> writes:
Samuel MV wrote:
 Thank you, Walter.
 
 D 1.0 is going to be THE BEST general purpose language ... :D

...or such :P
Dec 10 2006
prev sibling next sibling parent reply Pragma <ericanderton yahoo.removeme.com> writes:
Walter Bright wrote:
 More ABI changes, and implicit [] => * no longer allowed.
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.175.zip

Walter, this is a great update. Especially the removal of the implicit cast for array pointers. But I'd like to echo the other comments in this thread regarding structs. IMO, we're not there yet. I think folks are looking for a solution that does this: - A ctor like syntax for creating a new struct - No more forced copy of the entire struct on creation - Something that is disambiguated from static opCall - Ctors that are as clear to read as this() in classes and modules. Again, thanks for the solid push to 1.0 this month. I'm sure we haven't seen anything yet. -- - EricAnderton at yahoo
Dec 11 2006
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Pragma wrote:
<snip>
 But I'd like to echo the other comments in this thread regarding 
 structs.  IMO, we're not there yet.  I think folks are looking for a 
 solution that does this:
 
 - A ctor like syntax for creating a new struct
 - No more forced copy of the entire struct on creation

What do you mean by this?
 - Something that is disambiguated from static opCall

Do you mean that constructors for structs should have a notation distinct from S(...)? Stewart.
Dec 11 2006
parent reply Pragma <ericanderton yahoo.removeme.com> writes:
Stewart Gordon wrote:
 Pragma wrote:
 <snip>
 But I'd like to echo the other comments in this thread regarding 
 structs.  IMO, we're not there yet.  I think folks are looking for a 
 solution that does this:

 - A ctor like syntax for creating a new struct
 - No more forced copy of the entire struct on creation

What do you mean by this?

I'm glad you asked. :) Static opCall() is not a ctor. It never was. People have been clamoring to be able to use this() inside of a struct, much like they can with classes and modules. But the desire here goes beyond mere symmetry between type definitions. The forced copy issue is something that is an artifact of emulating a constructor for a struct. Take the standard approach for example: struct Foo{ int a,b,c; } Foo f = {a:1, b:2, c:3}; Foo f = {1,2,3}; // more succinct version So here we create a struct in place, and break encapsulation in the process. What we really want is an opaque type, that has a little more smarts on creation. Taking advantage of in/body/out would be nice too. No problem, we'll just use opCall(): struct Foo{ int a,b,c; static Foo opCall(int a,int b,int c){ Foo _this; _this.a = a; _this.b = b; _this.c = c; return _this; } } Foo f = Foo(1,2,3); That's better, but look at what's really happening here. Inlining and compiler optimization aside, the 'constructor' here creates a Foo on the stack which is then returned and *copied* to the destination 'f'. To most, that won't ever seem like a problem. But for folks who are working with Vector types or Matrix implementations, that's something to scream about. In a nutshell, any struct wider than a register that is populated in the 100's to 1000's is wasting cycles needlessly. So that brings us to something like this: struct Foo{ int a,b,c; this(int a,int b,int c){ this.a = a; this.b = b; this.c = c; } } Foo f = Foo(1,2,3); Ambiguity aside, this fixes encapsulation, gives a familiar syntax, and almost fixes the allocation issues. (see below)
 
 - Something that is disambiguated from static opCall

Do you mean that constructors for structs should have a notation distinct from S(...)?

Well, I think it's one of the reasons why we don't have ctors for structs right now. The preferred syntax for a "struct ctor" would probably be this: S foo = S(a,b,c); Which is indistinct from "static opCall". Throwing 'new' in there wouldn't work either, since that would be a dynamic allocation: S* foo = new S(a,b,c); So that leaves us with "something else" that provides both a way to invoke a ctor, yet allocates the data on the stack and doesn't force you to create an additional copy: S foo(a,b,c); // c++ style S foo = stackalloc S(a,b,c); // alloca() style (in place of new) S foo = new(stack) S(a,b,c): // another idea -- - EricAnderton at yahoo
Dec 12 2006
next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Pragma" <ericanderton yahoo.removeme.com> wrote in message 
news:elmhtj$1qv7$1 digitaldaemon.com...

 Well, I think it's one of the reasons why we don't have ctors for structs 
 right now.  The preferred syntax for a "struct ctor" would probably be 
 this:

 S foo = S(a,b,c);

 Which is indistinct from "static opCall".  Throwing 'new' in there 
 wouldn't work either, since that would be a dynamic allocation:

 S* foo = new S(a,b,c);

 So that leaves us with "something else" that provides both a way to invoke 
 a ctor, yet allocates the data on the stack and doesn't force you to 
 create an additional copy:

 S foo(a,b,c);  // c++ style
 S foo = stackalloc S(a,b,c); // alloca() style (in place of new)
 S foo = new(stack) S(a,b,c): // another idea

Personally for in-place stack allocation, I like the C++ style the best. It's the simplest to deal with for the compiler (it's 100% obvious that it's being created on the stack and there's no need for optimization to take care of anything). And it makes sense -- it says "make this a local variable, but call the constructor on it as well." There's no assignment so it doesn't look like any copying is going on.
Dec 12 2006
prev sibling next sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Pragma wrote:
 Foo f = Foo(1,2,3);
 
 That's better, but look at what's really happening here.  Inlining and 
 compiler optimization aside, the 'constructor' here creates a Foo on the 
 stack which is then returned and *copied* to the destination 'f'.

About this optimization business, is this an issue? Since Walter stated that such copies are optimized away (trivially?), my assumption was that the syntax as it is now relies on this optimization being present. Or to put it in other words, static opCall would not be supported if there was no such optimization possible. Perhaps it is similar to how the use of functors with templates in C++ rely on inlining, STL would be so slow without such optimizations. My question is if it is reasonable to make this assumption or can you put compiler optimization aside?
Dec 12 2006
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Lutger" <lutger.blijdestijn gmail.com> wrote in message 
news:elmjl8$1tdg$1 digitaldaemon.com...

 About this optimization business, is this an issue? Since Walter stated 
 that such copies are optimized away (trivially?), my assumption was that 
 the syntax as it is now relies on this optimization being present. Or to 
 put it in other words, static opCall would not be supported if there was 
 no such optimization possible.
 Perhaps it is similar to how the use of functors with templates in C++ 
 rely on inlining, STL would be so slow without such optimizations.

 My question is if it is reasonable to make this assumption or can you put 
 compiler optimization aside?

The impression I get from Walter is that _eeeevery_ compiler has optimization, so it's a nonissue. :P Optimization should be an entirely optional pass. Making language features rely on it seems hackish at best.
Dec 12 2006
next sibling parent Pragma <ericanderton yahoo.removeme.com> writes:
Jarrett Billingsley wrote:
 "Lutger" <lutger.blijdestijn gmail.com> wrote in message 
 news:elmjl8$1tdg$1 digitaldaemon.com...
 
 About this optimization business, is this an issue? Since Walter stated 
 that such copies are optimized away (trivially?), my assumption was that 
 the syntax as it is now relies on this optimization being present. Or to 
 put it in other words, static opCall would not be supported if there was 
 no such optimization possible.
 Perhaps it is similar to how the use of functors with templates in C++ 
 rely on inlining, STL would be so slow without such optimizations.

 My question is if it is reasonable to make this assumption or can you put 
 compiler optimization aside?

The impression I get from Walter is that _eeeevery_ compiler has optimization, so it's a nonissue. :P Optimization should be an entirely optional pass. Making language features rely on it seems hackish at best.

Exactly. Moreover, it's not always possible to inline or optimize even by a compiler that can do it well, so it *must* be optional by definition. Also there are some rather significant "edge cases" involved here. What about libraries, or reflection? -- - EricAnderton at yahoo
Dec 12 2006
prev sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Jarrett Billingsley wrote:
 "Lutger" <lutger.blijdestijn gmail.com> wrote in message 
 news:elmjl8$1tdg$1 digitaldaemon.com...
 
 About this optimization business, is this an issue? Since Walter stated 
 that such copies are optimized away (trivially?), my assumption was that 
 the syntax as it is now relies on this optimization being present. Or to 
 put it in other words, static opCall would not be supported if there was 
 no such optimization possible.
 Perhaps it is similar to how the use of functors with templates in C++ 
 rely on inlining, STL would be so slow without such optimizations.

 My question is if it is reasonable to make this assumption or can you put 
 compiler optimization aside?

The impression I get from Walter is that _eeeevery_ compiler has optimization, so it's a nonissue. :P Optimization should be an entirely optional pass. Making language features rely on it seems hackish at best.

Can you explain why? 'Rely' in this context doesn't mean the language is broken right? It just means it is slower, but isn't that expected from a non-optimizing compiler anyway?
Dec 12 2006
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Lutger" <lutger.blijdestijn gmail.com> wrote in message 
news:elmkes$1ult$1 digitaldaemon.com...

 Can you explain why? 'Rely' in this context doesn't mean the language is 
 broken right? It just means it is slower, but isn't that expected from a 
 non-optimizing compiler anyway?

Yes, I guess that's true. But if a simple addition i.e. x = a + b; Compiled to mov _TEMP1, a mov _TEMP2, b add _TEMP1, _TEMP2 mov x, _TEMP1 Instead of mov x, a add x, b It'd still be semantically correct, but would it make sense? In the same way, I don't see why the compiler should introduce a needless bit-copy of a (possibly large) structure which can *always* be optimized out when it would be much simpler to skip the bit-copy in the first place. It's an optimization which can always be performed, and so should not be an optimization. It should be the default behavior.
Dec 12 2006
parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Jarrett Billingsley wrote:
<snip>
 Yes, I guess that's true.  But if a simple addition i.e.
 
 x = a + b;
 
 Compiled to
 
 mov _TEMP1, a
 mov _TEMP2, b
 add _TEMP1, _TEMP2
 mov x, _TEMP1
 
 Instead of
 
 mov x, a
 add x, b
 
 It'd still be semantically correct, but would it make sense?

Almost. I could see it generate the following code (with optimizations turned off): mov _TEMP, a add _TEMP, b mov x, _TEMP where a, b and x are memory locations and _TEMP is a register. On x86, you can't add the contents of two memory locations, at least one of the values needs to be in a register. With optimizations on, of course, the variables might be stored in registers instead of memory. If so, your proposed code would be legal.
Dec 12 2006
prev sibling next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Pragma wrote:
 That's better, but look at what's really happening here.  Inlining and 
 compiler optimization aside, the 'constructor' here creates a Foo on the 
 stack which is then returned and *copied* to the destination 'f'.

That problem was solved 15 years ago (for C and C++). I admit that due to sloth I had failed to implement the solution yet in dmd, but it is implemented now and will go out in the next update. There will be NO extra copies. For whatever the merits of opCall vs this(), efficiency is NOT a problem with either, and is not a reason to choose one or the other. The generated code is the same. Under the hood, they are the same. Both take a hidden pointer to where the result is stored. The rest is window dressing.
Dec 12 2006
next sibling parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:
 Under the hood, they are the same. Both take a hidden pointer to where 
 the result is stored. The rest is window dressing.

That means you can't return the result in a register :o). Andrei
Dec 12 2006
next sibling parent Sean Kelly <sean f4.ca> writes:
Andrei Alexandrescu (See Website For Email) wrote:
 Walter Bright wrote:
 Under the hood, they are the same. Both take a hidden pointer to where 
 the result is stored. The rest is window dressing.

That means you can't return the result in a register :o).

That talk can stay on comp.lang.c++.moderated, thank you very much ;-) Sean
Dec 12 2006
prev sibling parent Walter Bright <newshound digitalmars.com> writes:
Andrei Alexandrescu (See Website For Email) wrote:
 Walter Bright wrote:
 Under the hood, they are the same. Both take a hidden pointer to where 
 the result is stored. The rest is window dressing.

That means you can't return the result in a register :o).

Actually, it does return it in a register if it fits in one. Try it!
Dec 13 2006
prev sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:elnv14$r2d$1 digitaldaemon.com...

 For whatever the merits of opCall vs this(), efficiency is NOT a problem 
 with either, and is not a reason to choose one or the other. The generated 
 code is the same.

 Under the hood, they are the same. Both take a hidden pointer to where the 
 result is stored. The rest is window dressing.

Alright then. All I've got then is the orthogonality argument. But you won't listen to that either. People will come to D from C++ and C# and ask "where are constructors in structs?" and we'll say "you have to use static opCall." And they'll ask "why?" And all we'll be able to do is shake our heads, sigh, and say "I don't know." For the last time, even though you don't care: we have been using static opCall as a WORKAROUND. As in *we never intended for that to be the canonical method of constructing a struct*. I don't think anyone would complain if they were given a consistent, logical method of initializing any aggregate type.
Dec 13 2006
next sibling parent reply "Chris Miller" <chris dprogramming.com> writes:
On Wed, 13 Dec 2006 12:02:37 -0500, Jarrett Billingsley  
<kb3ctd2 yahoo.com> wrote:

 "Walter Bright" <newshound digitalmars.com> wrote in message
 news:elnv14$r2d$1 digitaldaemon.com...

 For whatever the merits of opCall vs this(), efficiency is NOT a problem
 with either, and is not a reason to choose one or the other. The  
 generated
 code is the same.

 Under the hood, they are the same. Both take a hidden pointer to where  
 the
 result is stored. The rest is window dressing.

Alright then. All I've got then is the orthogonality argument. But you won't listen to that either. People will come to D from C++ and C# and ask "where are constructors in structs?" and we'll say "you have to use static opCall." And they'll ask "why?" And all we'll be able to do is shake our heads, sigh, and say "I don't know." For the last time, even though you don't care: we have been using static opCall as a WORKAROUND. As in *we never intended for that to be the canonical method of constructing a struct*. I don't think anyone would complain if they were given a consistent, logical method of initializing any aggregate type.

For the record, I'm fine with static opCall. Structs don't have constructors and destructors, but the language just so happens to allow us to have something that looks like a constructor. We could use Foo.create() to initialize new Foo`s but since opCall is available and looks nice to us, we can go with it. If opCall didn't exist, would we even be having this argument? We would know structs weren't meant to have true constructors and destructors. We have an aesthetically pleasing way to initialize structs, so what's the problem. If your friend asks if structs have constructors, you say no, but since the langauge is so expressive, you have this feature called opCall that makes it just as nice to initialize. P.S. I actually don't want a defensive response to this, I'm just stating my view; thanks.
Dec 13 2006
parent reply Mark Wrenn <mark binarytheory.com> writes:
On Wed, 13 Dec 2006 12:21:37 -0500, Chris Miller wrote:

"We know structs weren't meant to have true constructors and destructors.
We have an aesthetically pleasing way to initialize structs, so what's the
problem. If your friend asks if structs have constructors, you say no, but
since the langauge is so expressive, you have this feature called opCall
that makes it just as nice to initialize."

*Amen*
Dec 13 2006
parent "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Mark Wrenn wrote:
 On Wed, 13 Dec 2006 12:21:37 -0500, Chris Miller wrote:
 
 "We know structs weren't meant to have true constructors and destructors.
 We have an aesthetically pleasing way to initialize structs, so what's the
 problem. If your friend asks if structs have constructors, you say no, but
 since the langauge is so expressive, you have this feature called opCall
 that makes it just as nice to initialize."
 
 *Amen*

If structs do add destructors, this can will be reopened - and by that time it will be much more smellier. Andrei
Dec 13 2006
prev sibling next sibling parent "Lionello Lunesu" <lionello lunesu.remove.com> writes:
Let's not forget that the members of a struct can be initialized "inline":

struct X {
  int a = 2;
}

This makes the lack of constructors for structs a lot less significant.

Additionally, destructors for structs are primarily used for wrappers, RAII, 
and let's not forget scope(...), which is much better suited for RAII than 
destructors ever were. It makes the lack of destructors for structs a lot 
less significant..

So, if people want a C++-looking initialize function, they can use static 
opCall, and it'll look like a call to a constructor (ie. having the same 
name as the struct).

L. 
Dec 13 2006
prev sibling parent Leopold Walkling <leopold_walkling web.de> writes:
Jarrett Billingsley schrieb:
 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:elnv14$r2d$1 digitaldaemon.com...
 
 For whatever the merits of opCall vs this(), efficiency is NOT a problem 
 with either, and is not a reason to choose one or the other. The generated 
 code is the same.

 Under the hood, they are the same. Both take a hidden pointer to where the 
 result is stored. The rest is window dressing.

Alright then. All I've got then is the orthogonality argument. But you won't listen to that either. People will come to D from C++ and C# and ask "where are constructors in structs?" and we'll say "you have to use static opCall." And they'll ask "why?" And all we'll be able to do is shake our heads, sigh, and say "I don't know." For the last time, even though you don't care: we have been using static opCall as a WORKAROUND. As in *we never intended for that to be the canonical method of constructing a struct*. I don't think anyone would complain if they were given a consistent, logical method of initializing any aggregate type.

To me another big problem is the cast to a struct. How could anyone, who is new to D/ didn't study the spec enough expect, that a cast to a struct is done by calling the "opCall". One of those who came from C++ (like me too) would expect the static opCall as the equivalent to those rather rarely used C++-operator()() overloads. What could one answer if some of them ask why it's like this? Couldn't there just be another name than static opCall? Then, to keep it from being ambigous, there could be a change of the let's say opCreate syntax. It doesn't has to be like in C++, I imagine something in the direction of static struct initializers: struct A { int i, j; } int v = 9; A a = A:{a:10, j:v /*not only constants*/};
Dec 14 2006
prev sibling parent Burton Radons <burton-radons smocky.com> writes:
Pragma wrote:
 Stewart Gordon wrote:
 Pragma wrote:
 <snip>
 But I'd like to echo the other comments in this thread regarding 
 structs.  IMO, we're not there yet.  I think folks are looking for a 
 solution that does this:

 - A ctor like syntax for creating a new struct
 - No more forced copy of the entire struct on creation

What do you mean by this?

I'm glad you asked. :) Static opCall() is not a ctor. It never was. People have been clamoring to be able to use this() inside of a struct, much like they can with classes and modules. But the desire here goes beyond mere symmetry between type definitions. The forced copy issue is something that is an artifact of emulating a constructor for a struct. Take the standard approach for example: struct Foo{ int a,b,c; } Foo f = {a:1, b:2, c:3}; Foo f = {1,2,3}; // more succinct version So here we create a struct in place, and break encapsulation in the process. What we really want is an opaque type, that has a little more smarts on creation. Taking advantage of in/body/out would be nice too. No problem, we'll just use opCall(): struct Foo{ int a,b,c; static Foo opCall(int a,int b,int c){ Foo _this; _this.a = a; _this.b = b; _this.c = c; return _this; } } Foo f = Foo(1,2,3); That's better, but look at what's really happening here. Inlining and compiler optimization aside, the 'constructor' here creates a Foo on the stack which is then returned and *copied* to the destination 'f'.

If that's not compiled into a direct write (even to the point of keeping the value virtual unless if it's actually needed in contiguous memory) then there's something wrong with the optimiser.
 To most, that won't ever seem like a problem. But for folks who are 
 working with Vector types or Matrix implementations, that's something to 
 scream about.  In a nutshell, any struct wider than a register that is 
 populated in the 100's to 1000's is wasting cycles needlessly.

I've never liked doing that - if you're going to have very large vectors or matrices, it's usually better just to switch to a programmatic model (run-time sized) rather than keeping it parametric (templated). At some point you're spending more time compiling than you are executing. This requires duplication of a lot of code, which is unacceptable. I've been thinking about this problem for a long time and I still have no solution to it (mixins are so very not the right way); perhaps we're misconsidering how parametric and programmatic types should interact. Let's say that the values used in the constructor of a type are recorded. So we might have (excuse the language): #!/usr/bin/moki --version=1 #using: #moki.(size, static array); Matrix := #class { data : static array of (type, rows, cols); // No content needed. #this (type, rows : size, cols : size); }; Now "rows" and "cols" are both automatically constant properties of any created Matrix. If our algorithm requires certain limitations on the matrix, we can "specialise" it: transpose (matrix : Matrix (type, rows, rows)) : Matrix (type, rows, rows) ... And the compiler can generally optimise the Matrix like it were parametric - it could even apply discretionary optimisation so that it doesn't waste compile time on what doesn't even matter - but you could still use it programmatically.
 So that brings us to something like this:
 
 struct Foo{
   int a,b,c;
   this(int a,int b,int c){
     this.a = a;
     this.b = b;
     this.c = c;
   }
 }
 
 Foo f = Foo(1,2,3);
 
 Ambiguity aside, this fixes encapsulation, gives a familiar syntax, and 
 almost fixes the allocation issues.  (see below)

There's still an implied copy, but again, that shouldn't be relevant for any properly-working optimiser.
 - Something that is disambiguated from static opCall

Do you mean that constructors for structs should have a notation distinct from S(...)?

Well, I think it's one of the reasons why we don't have ctors for structs right now. The preferred syntax for a "struct ctor" would probably be this: S foo = S(a,b,c); Which is indistinct from "static opCall". Throwing 'new' in there wouldn't work either, since that would be a dynamic allocation: S* foo = new S(a,b,c);

"new <struct>" didn't used to parse, and I argued then that it shouldn't because everywhere else the "new" operator exactly described the type it would create. If this special case were removed, it could work as a constructor call. But really I think static opCall should just be killed off.
 So that leaves us with "something else" that provides both a way to 
 invoke a ctor, yet allocates the data on the stack and doesn't force you 
 to create an additional copy:
 
 S foo(a,b,c);  // c++ style
 S foo = stackalloc S(a,b,c); // alloca() style (in place of new)
 S foo = new(stack) S(a,b,c): // another idea
 

Dec 21 2006
prev sibling next sibling parent Alexander Panek <a.panek brainsware.org> writes:
http://digitalmars.com/d/attribute.html#align

--
AlignAttribute:
	align
	align ) Integer )
--

I guess this was meant to be:

--
AlignAttribute:
	align
	align ( Integer )
--


Apart from that .. I just found several new things in the documentation, 
scary. :P
Dec 12 2006
prev sibling parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Walter Bright wrote:
 More ABI changes, and implicit [] => * no longer allowed.
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.175.zip

Looks like casts from void* to struct* is broken. Russ
Dec 15 2006
parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Russ Lewis wrote:
 Walter Bright wrote:
 
 More ABI changes, and implicit [] => * no longer allowed.

 http://www.digitalmars.com/d/changelog.html

 http://ftp.digitalmars.com/dmd.175.zip

Looks like casts from void* to struct* is broken. Russ

Not sure what I did wrong or what I'm doing right now, but they seem to be working. Sorry for any confusion I caused.
Dec 21 2006