www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DIP25 draft available for destruction

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Probably it'll need a fair amount of tweaking. Anyhow it's in 
destroyable form.

http://wiki.dlang.org/DIP25


Thanks,

Andrei
Feb 05 2013
next sibling parent kenji hara <k.hara.pg gmail.com> writes:
2013/2/6 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>


 Probably it'll need a fair amount of tweaking. Anyhow it's in destroyable
 form.

 http://wiki.dlang.org/DIP25



Hmm, this is much reasonable.

In recent, I had wrote and post a compiler extension to reinforce a kind of
trait which related to pure function. I call the trait "isolated", and that
means "Whether any reachable indirections from parameters does not appear
in the returned value".

https://github.com/D-Programming-Language/dmd/pull/1519

With my patch, such as following cases can be detected.

struct S { int* ptr; }
S foo(int* ptr) pure;
S bar(const int* ptr) pure;

void main() {
  int n;
  immutable S s = foo(&n);
  // implicit conversion from S to immutable S is _diallowed_.
  // Because &n may appear in foo's returned value.

  immutable S s = bar(&n);
  // implicit conversion from S to immutable S is _allowed_.
  // Because &n never appear in bar's returned value.
  // (compiler assumes that bar doesn't do any un- safe operations, e.g.
cast(int*)ptr)
}

As far as I see, the contained essence in the DIP is much similar to the
"isolated" traits.
So I can say that it is *implementable*.

Kenji Hara
Feb 06 2013
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Wed, 06 Feb 2013 02:38:17 -0500
schrieb Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>:


 Probably it'll need a fair amount of tweaking. Anyhow it's in 
 destroyable form.
 
 http://wiki.dlang.org/DIP25
 
 
 Thanks,
 
 Andrei


Sounds good.
Regarding rule 2.2:

I think somebody already said that classes could be allocated on
the stack but I guess we can't do anything about that. At least in
 safe code placing a class on the stack should be illegal though, so we
can partially avoid the problem there.
If we have such a special rule for classes would it also make sense to
have a similar rule for struct*?
Feb 06 2013
prev sibling next sibling parent reply Chad Joan <chadjoan gmail.com> writes:
On 02/06/2013 02:38 AM, Andrei Alexandrescu wrote:

 Probably it'll need a fair amount of tweaking. Anyhow it's in
 destroyable form.

 http://wiki.dlang.org/DIP25


 Thanks,

 Andrei


This is probably reasonably, but I'm having trouble fully comprehending it.

Once I get to the "Typechecking rules" section and dig into the 
nitty-gritty, it seems to be written in a way that discusses what is 
allowed, but only briefly hints at what is disallowed.  It is not 
immediately clear to me how this would impact my code.

My interpretation so far is that the only difference between DIP25 and 
current D code is that we won't be allowed to pass stack variables 
(including by-value/copied parameters) into ref parameters.

HTH
Feb 06 2013
next sibling parent reply Chad Joan <chadjoan gmail.com> writes:
On 02/06/2013 09:48 AM, Chad Joan wrote:

 Once I get to the "Typechecking rules" section and dig into the
 nitty-gritty, it seems to be written in a way that discusses what is
 allowed, but only briefly hints at what is disallowed. It is not
 immediately clear to me how this would impact my code.


I should be more clear myself: I mean "Typechecking rules" and 
everything that follows it.
Feb 06 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/6/13 9:49 AM, Chad Joan wrote:

 On 02/06/2013 09:48 AM, Chad Joan wrote:

 Once I get to the "Typechecking rules" section and dig into the
 nitty-gritty, it seems to be written in a way that discusses what is
 allowed, but only briefly hints at what is disallowed. It is not
 immediately clear to me how this would impact my code.


 I should be more clear myself: I mean "Typechecking rules" and
 everything that follows it.


Yah, we need more examples. As for what's disallowed, in a way it's 
"simple" - everything that's not allowed is disallowed :o).

We definitely should add discussion of disallowed uses.


Andrei
Feb 06 2013
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/6/13 9:48 AM, Chad Joan wrote:

 My interpretation so far is that the only difference between DIP25 and
 current D code is that we won't be allowed to pass stack variables
 (including by-value/copied parameters) into ref parameters.


Hmm, I need to make things clearer. That's covered plainly in 1.1. You 
get to pass down stack variables and by-value parameters down to 
functions taking ref. You won't be able to return them up, no matter 
what you (safely) try.

Andrei
Feb 06 2013
prev sibling next sibling parent "Zach the Mystic" <reachBUTMINUSTHISzach gOOGLYmail.com> writes:
On Wednesday, 6 February 2013 at 07:38:17 UTC, Andrei 
Alexandrescu wrote:

 Probably it'll need a fair amount of tweaking. Anyhow it's in 
 destroyable form.

 http://wiki.dlang.org/DIP25


 Thanks,

 Andrei


All of the 'fine' ones are fine. Which leaves how one might 
invoke the 'unfine' ones. The language must make a choice between 
restricted simplicity and flexible complexity. If it chooses 
flexibility, the function signature must give a clue as to what 
the return value contains. 'out' return values and 'scope' 
parameters will give the clues it needs.

Here are all the 'unfine' functions listed:

ref T gun(ref T);
struct S { int a; T b; }
ref S iun(ref S);

ref T caller(bool condition, ref T v1, ref S v2, T v3, S v4) {
     T v5;
     S v6;

     // Not fine, bound to locals
     // if (condition) return gun(v3);
     // if (condition) return gun(v4.b);
     // if (condition) return gun(v5);
     // if (condition) return gun(v6.b);

     // Not fine, bound to locals
     // if (condition) return iun(v4);
     // if (condition) return iun(v6);
}

Say gun's actual implementation is:

ref T gun(ref T a) {
    auto noo = new T;
    noo = a;
    return noo;
}

You can' tell from the function signature that the return value 
of this function is good to go, so the call 'return gun(v3);' 
above would be disallowed even though it didn't need to be. If 
you marked the signature with 'out', the caller knows it's good 
to go, and the compiler can statically prevent the function from 
returning one of its ref parameters. 'out' can be made to imply 
'ref' in any case where the type is not inherently a reference 
anyway.

out T gun(ref T a) {
    return new T; // Pass
    return a; // Error
}

This will solve all problems, except for the very rare corner 
case when you need to assert fined-grained control over exactly 
which ref parameters are safe and which are not. 'scope' comes to 
the rescue here.

ref int fud(ref int a, scope int b) {
    a += b;
    return a; // Pass

    return b; // Error
}
ref int elmer(ref int f) {
    int v;
    return fud(f, v); // Passes
    return fud(v, f); // Fails
}

An 'out' return value simply marks all its 'ref' parameters 
'scope' underneath the hood, so there will never be a need for 
both 'out' and 'scope' in the same signature. Since 'scope' is 
useless if its not a reference, it implies 'ref' also.

I'm pretty sure this is the best way to make the language 
completely flexible. I don't anticipate an easier way to get it 
done, and therefore, to my mind at least, the choice is between 
simple-but-limited and flexible-and-complicated.
Feb 06 2013
prev sibling next sibling parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 06.02.2013 08:38, schrieb Andrei Alexandrescu:

 Probably it'll need a fair amount of tweaking. Anyhow it's in
 destroyable form.

 http://wiki.dlang.org/DIP25


 Thanks,

 Andrei


What I don't get is, why is it better to have a function 
"addressOf(value)" that does exactly the same as &value? Expect that it 
is more text to type? Why is addressOf(value) more explicit then &value?

Kind Regards
Benjamin Thaut
Feb 06 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/6/13 12:33 PM, Benjamin Thaut wrote:

 Am 06.02.2013 08:38, schrieb Andrei Alexandrescu:

 Probably it'll need a fair amount of tweaking. Anyhow it's in
 destroyable form.

 http://wiki.dlang.org/DIP25


 Thanks,

 Andrei


 What I don't get is, why is it better to have a function
 "addressOf(value)" that does exactly the same as &value? Expect that it
 is more text to type? Why is addressOf(value) more explicit then &value?


A good part of that is the recent debate on what &func should do (take 
the address of the function vs. the address of its result). With the 
unsafe meaning out of the way, only the safe one is eligible.

Andrei
Feb 06 2013
next sibling parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 06.02.2013 18:36, schrieb Andrei Alexandrescu:

 On 2/6/13 12:33 PM, Benjamin Thaut wrote:

 Am 06.02.2013 08:38, schrieb Andrei Alexandrescu:

 Probably it'll need a fair amount of tweaking. Anyhow it's in
 destroyable form.

 http://wiki.dlang.org/DIP25


 Thanks,

 Andrei


 What I don't get is, why is it better to have a function
 "addressOf(value)" that does exactly the same as &value? Expect that it
 is more text to type? Why is addressOf(value) more explicit then &value?


 A good part of that is the recent debate on what &func should do (take
 the address of the function vs. the address of its result). With the
 unsafe meaning out of the way, only the safe one is eligible.

 Andrei


Ok that makes sense, you might want to add that as a explanation to the 
DIP.

So the &value expression would only be left for taking addresses of 
functions? Wouldn't it make more sense to do it the other way around? 
E.g. create some utilty function that is only there for taking the 
address of functions and disallowing to do so by using &func?

Kind Regards
Benjamin Thaut
Feb 06 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/6/13 12:40 PM, Benjamin Thaut wrote:

 So the &value expression would only be left for taking addresses of
 functions? Wouldn't it make more sense to do it the other way around?
 E.g. create some utilty function that is only there for taking the
 address of functions and disallowing to do so by using &func?


I don't think that would work without adding new keywords.

Andrei
Feb 06 2013
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 06.02.2013 18:50, schrieb Andrei Alexandrescu:

 On 2/6/13 12:40 PM, Benjamin Thaut wrote:

 So the &value expression would only be left for taking addresses of
 functions? Wouldn't it make more sense to do it the other way around?
 E.g. create some utilty function that is only there for taking the
 address of functions and disallowing to do so by using &func?


 I don't think that would work without adding new keywords.

 Andrei


Whats so bad about adding a new keyword for this?

I fear that newcomers will find taking addresses pretty inconsistens if 
we implement this proposal. Because the language will have the take 
address operator "&" they know from c++, but it only works in some 
special cases. For all other cases addressOf has to be used. It would be 
much more consistent if you could use the "&" operator for everything 
but taking the address of a function. That would be more consistent in 
my opinion.

Lately I'm getting the feeling that D 2.0 is becoming a collection of 
hacks to workaround issues which could be solved by adding new keywords 
or doing other major changes. (like all the stuff that starts with __)

Kind Regards
Benjamin Thaut
Feb 06 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/6/13 1:39 PM, Benjamin Thaut wrote:

 Am 06.02.2013 18:50, schrieb Andrei Alexandrescu:

 On 2/6/13 12:40 PM, Benjamin Thaut wrote:

 So the &value expression would only be left for taking addresses of
 functions? Wouldn't it make more sense to do it the other way around?
 E.g. create some utilty function that is only there for taking the
 address of functions and disallowing to do so by using &func?


 I don't think that would work without adding new keywords.

 Andrei


 Whats so bad about adding a new keyword for this?


This is an ill-posed question. A keyword should justify its utility, not 
prove it doesn't harm.


 I fear that newcomers will find taking addresses pretty inconsistens if
 we implement this proposal. Because the language will have the take
 address operator "&" they know from c++, but it only works in some
 special cases. For all other cases addressOf has to be used. It would be
 much more consistent if you could use the "&" operator for everything
 but taking the address of a function. That would be more consistent in
 my opinion.


It would be more consistent with C++, but less so with the notion of 
safety. I find it very consistent that all uses of &expression are safe, 
and this is the kind of consistency Walter and I believe is worth aiming 
for.


 Lately I'm getting the feeling that D 2.0 is becoming a collection of
 hacks to workaround issues which could be solved by adding new keywords
 or doing other major changes. (like all the stuff that starts with __)


I can't help how you feel, but I think you're wrong here and I don't 
know what other cases you're referring to.


Andrei
Feb 06 2013
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 02/06/2013 08:12 PM, Andrei Alexandrescu wrote:

 On 2/6/13 1:39 PM, Benjamin Thaut wrote:

 Am 06.02.2013 18:50, schrieb Andrei Alexandrescu:

 On 2/6/13 12:40 PM, Benjamin Thaut wrote:

 So the &value expression would only be left for taking addresses of
 functions? Wouldn't it make more sense to do it the other way around?
 E.g. create some utilty function that is only there for taking the
 address of functions and disallowing to do so by using &func?


 I don't think that would work without adding new keywords.

 Andrei


 Whats so bad about adding a new keyword for this?


 This is an ill-posed question. A keyword should justify its utility, not
 prove it doesn't harm.


 I fear that newcomers will find taking addresses pretty inconsistens if
 we implement this proposal. Because the language will have the take
 address operator "&" they know from c++, but it only works in some
 special cases. For all other cases addressOf has to be used. It would be
 much more consistent if you could use the "&" operator for everything
 but taking the address of a function. That would be more consistent in
 my opinion.


 It would be more consistent with C++, but less so with the notion of
 safety. I find it very consistent that all uses of &expression are safe,
 and this is the kind of consistency Walter and I believe is worth aiming
 for.


So you are saying this should compile?:

struct S{
     int x;
     int foo() safe{ return x; }
}

int delegate() safe foo() safe{
     S s;
     return &s.foo;
}



 Lately I'm getting the feeling that D 2.0 is becoming a collection of
 hacks to workaround issues which could be solved by adding new keywords
 or doing other major changes. (like all the stuff that starts with __)


 I can't help how you feel, but I think you're wrong here and I don't
 know what other cases you're referring to.


+1.
Feb 06 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/6/13 5:05 PM, Timon Gehr wrote:

 On 02/06/2013 08:12 PM, Andrei Alexandrescu wrote:

 It would be more consistent with C++, but less so with the notion of
 safety. I find it very consistent that all uses of &expression are safe,
 and this is the kind of consistency Walter and I believe is worth aiming
 for.


 So you are saying this should compile?:

 struct S{
 int x;
 int foo() safe{ return x; }
 }

 int delegate() safe foo() safe{
 S s;
 return &s.foo;
 }


Yah, it should, and it also should detect the escape and allocate foo's 
frame on the heap.

Andrei
Feb 06 2013
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 02/06/2013 11:14 PM, Andrei Alexandrescu wrote:

 On 2/6/13 5:05 PM, Timon Gehr wrote:

 On 02/06/2013 08:12 PM, Andrei Alexandrescu wrote:

 It would be more consistent with C++, but less so with the notion of
 safety. I find it very consistent that all uses of &expression are safe,
 and this is the kind of consistency Walter and I believe is worth aiming
 for.


 So you are saying this should compile?:

 struct S{
     int x;
     int foo() safe{ return x; }
 }

 int delegate() safe foo() safe{
     S s;
     return &s.foo;
 }


 Yah, it should, and it also should detect the escape and allocate foo's
 frame on the heap.

 Andrei


I see. Generally?
Eg. this detects the escape and allocates as well?:

S* foo() safe{
     S s;
     return &s;
}
Feb 06 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/6/13 5:22 PM, Timon Gehr wrote:

 I see. Generally?
 Eg. this detects the escape and allocates as well?:

 S* foo() safe{
 S s;
 return &s;
 }


I think I'm starting to see what you're doing there :o).

Andrei
Feb 06 2013
parent "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 6 February 2013 at 22:33:57 UTC, Andrei 
Alexandrescu wrote:

 On 2/6/13 5:22 PM, Timon Gehr wrote:

 I see. Generally?
 Eg. this detects the escape and allocates as well?:

 S* foo() safe{
 S s;
 return &s;
 }


 I think I'm starting to see what you're doing there :o).


I have to admit this was a big puzzling point to me as well.
Feb 06 2013
prev sibling parent reply "Rob T" <alanb ucora.com> writes:
On Wednesday, 6 February 2013 at 22:14:42 UTC, Andrei 
Alexandrescu wrote:

 On 2/6/13 5:05 PM, Timon Gehr wrote:

 On 02/06/2013 08:12 PM, Andrei Alexandrescu wrote:

 It would be more consistent with C++, but less so with the 
 notion of
 safety. I find it very consistent that all uses of 
 &expression are safe,
 and this is the kind of consistency Walter and I believe is 
 worth aiming
 for.


 So you are saying this should compile?:

 struct S{
 int x;
 int foo() safe{ return x; }
 }

 int delegate() safe foo() safe{
 S s;
 return &s.foo;
 }


 Yah, it should, and it also should detect the escape and 
 allocate foo's frame on the heap.

 Andrei


I thought we wanted to minimize allocations, especially silent 
ones. In the quoted example, I'd rather the address taking be 
disallowed at compile time unless the programmer explicitly 
allocated S on the heap.

--rt
Feb 06 2013
parent reply "Rob T" <alanb ucora.com> writes:
On Thursday, 7 February 2013 at 05:37:44 UTC, Rob T wrote:

 On Wednesday, 6 February 2013 at 22:14:42 UTC, Andrei 
 Alexandrescu wrote:

 On 2/6/13 5:05 PM, Timon Gehr wrote:

 On 02/06/2013 08:12 PM, Andrei Alexandrescu wrote:

 It would be more consistent with C++, but less so with the 
 notion of
 safety. I find it very consistent that all uses of 
 &expression are safe,
 and this is the kind of consistency Walter and I believe is 
 worth aiming
 for.


 So you are saying this should compile?:

 struct S{
 int x;
 int foo() safe{ return x; }
 }

 int delegate() safe foo() safe{
 S s;
 return &s.foo;
 }


 Yah, it should, and it also should detect the escape and 
 allocate foo's frame on the heap.

 Andrei


 I thought we wanted to minimize allocations, especially silent 
 ones. In the quoted example, I'd rather the address taking be 
 disallowed at compile time unless the programmer explicitly 
 allocated S on the heap.

 --rt


In other words  safe should explicitly mean "I hereby verify that 
the code is safe" not "I will silently re-write your code in 
unknown ways to make it safe".

PLEASE reconsider!

--rt
Feb 06 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 7 February 2013 at 05:43:24 UTC, Rob T wrote:

 In other words  safe should explicitly mean "I hereby verify 
 that the code is safe" not "I will silently re-write your code 
 in unknown ways to make it safe".


 safe never meant that and Andrei never suggested that.
Feb 06 2013
parent reply "Rob T" <alanb ucora.com> writes:
On Thursday, 7 February 2013 at 05:54:29 UTC, deadalnix wrote:

 On Thursday, 7 February 2013 at 05:43:24 UTC, Rob T wrote:

 In other words  safe should explicitly mean "I hereby verify 
 that the code is safe" not "I will silently re-write your code 
 in unknown ways to make it safe".


  safe never meant that and Andrei never suggested that.


I must have misunderstood something. What did he mean by this?

------------

 So you are saying this should compile?:

 struct S{
 int x;
 int foo() safe{ return x; }
 }

 int delegate() safe foo() safe{
 S s;
 return &s.foo;
 }


Yah, it should, and it also should detect the escape and allocate 
foo's
frame on the heap.

Andrei
------------

What is being allocated on the heap?

--rt
Feb 07 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 7 February 2013 at 08:48:30 UTC, Rob T wrote:

 On Thursday, 7 February 2013 at 05:54:29 UTC, deadalnix wrote:

 On Thursday, 7 February 2013 at 05:43:24 UTC, Rob T wrote:

 In other words  safe should explicitly mean "I hereby verify 
 that the code is safe" not "I will silently re-write your 
 code in unknown ways to make it safe".


  safe never meant that and Andrei never suggested that.


 I must have misunderstood something. What did he mean by this?

 ------------

 So you are saying this should compile?:

 struct S{
 int x;
 int foo() safe{ return x; }
 }

 int delegate() safe foo() safe{
 S s;
 return &s.foo;
 }


 Yah, it should, and it also should detect the escape and 
 allocate foo's
 frame on the heap.

 Andrei
 ------------

 What is being allocated on the heap?


The frame pointer is, and it isn't dependent of  system or  safe .
Feb 07 2013
parent "Rob T" <alanb ucora.com> writes:
On Thursday, 7 February 2013 at 09:21:38 UTC, deadalnix wrote:

 On Thursday, 7 February 2013 at 08:48:30 UTC, Rob T wrote:

 On Thursday, 7 February 2013 at 05:54:29 UTC, deadalnix wrote:

 On Thursday, 7 February 2013 at 05:43:24 UTC, Rob T wrote:

 In other words  safe should explicitly mean "I hereby verify 
 that the code is safe" not "I will silently re-write your 
 code in unknown ways to make it safe".


  safe never meant that and Andrei never suggested that.


 I must have misunderstood something. What did he mean by this?

 ------------

 So you are saying this should compile?:

 struct S{
 int x;
 int foo() safe{ return x; }
 }

 int delegate() safe foo() safe{
 S s;
 return &s.foo;
 }


 Yah, it should, and it also should detect the escape and 
 allocate foo's
 frame on the heap.

 Andrei
 ------------

 What is being allocated on the heap?


 The frame pointer is, and it isn't dependent of  system or 
  safe .



S* foo() safe{
     S s;
     return &s;
}


In the above example, will s be silently allocated on the heap?

--rt
Feb 07 2013
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/6/13 12:36 PM, Andrei Alexandrescu wrote:

 On 2/6/13 12:33 PM, Benjamin Thaut wrote:

 Am 06.02.2013 08:38, schrieb Andrei Alexandrescu:

 Probably it'll need a fair amount of tweaking. Anyhow it's in
 destroyable form.

 http://wiki.dlang.org/DIP25


 Thanks,

 Andrei


 What I don't get is, why is it better to have a function
 "addressOf(value)" that does exactly the same as &value? Expect that it
 is more text to type? Why is addressOf(value) more explicit then &value?


 A good part of that is the recent debate on what &func should do (take
 the address of the function vs. the address of its result). With the
 unsafe meaning out of the way, only the safe one is eligible.


Added a dedicated section to the DIP: http://goo.gl/xkIXb

Andrei
Feb 06 2013
parent "Zach the Mystic" <reachBUTMINUSTHISzach gOOGLYmail.com> writes:
On Wednesday, 6 February 2013 at 17:50:06 UTC, Andrei 
Alexandrescu wrote:

 A good part of that is the recent debate on what &func should 
 do (take
 the address of the function vs. the address of its result). 
 With the
 unsafe meaning out of the way, only the safe one is eligible.


 Added a dedicated section to the DIP: http://goo.gl/xkIXb

 Andrei


As per your encouragement to me, I suggest using 'opAddress' 
instead of 'addressOf' to allow future compatibility with structs.
Feb 06 2013
prev sibling parent "Regan Heath" <regan netmail.co.nz> writes:
On Wed, 06 Feb 2013 17:36:24 -0000, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 A good part of that is the recent debate on what &func should do (take  
 the address of the function vs. the address of its result). With the  
 unsafe meaning out of the way, only the safe one is eligible.


&X takes the address of X.

If X is a symbol which represents an 'int' you get the address of the int  
itself, not the address of the int's value.

If X is a symbol which represents a 'function' you should get the address  
of the function itself, not the address of that functions value (AKA the  
result).

That seems the most logical thing to implement, to me.  I think the  
confusion arises because ppl conflate the symbol/variable/thing and that  
thing's value.

If we implement this we then have to ask how to get the address of the  
value.  I reckon; if you want the address of the value of the function  
then call the function and take the address of that i.e. &func().  Here,  
brackets are not optional because they indicate the function is being  
called.

Alternately if you don't like that, perhaps &*func.  So, if func is "ref  
int func()" then this syntax makes it analogous to an int* e.g.

int i = 5;
int *p = &i;

&p  // takes the address of the variable 'p'
&*p // takes the address of the variable 'i'

int i = 5;
ref int func() { return i; }

&func   // takes the address of func
&*func  // takes the address of i

I prefer:

&func() // takes the address of i

because to me that is clearer and nicer looking.

This seems the most logical thing to do, and seems the most flexible to  
me.  If &func were to take the address of the value of func (result) then  
we'd need to invent a new syntax to take the address of func itself and  
why do that when we don't really need to. IMO.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
Feb 07 2013
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/6/13 2:38 AM, Andrei Alexandrescu wrote:

 Probably it'll need a fair amount of tweaking. Anyhow it's in
 destroyable form.

 http://wiki.dlang.org/DIP25


Updated with a section dedicated to address taking:

http://wiki.dlang.org/DIP25#Taking_address


Andrei
Feb 06 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 06 Feb 2013 02:38:17 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 Probably it'll need a fair amount of tweaking. Anyhow it's in  
 destroyable form.

 http://wiki.dlang.org/DIP25


First reaction:

It should be GUARANTEED that addressOf is a simple load of the underlying  
pointer that ref represents.  That is, the library/compiler should be  
compelled not to call a specific function or otherwise execute anything  
but a simple load (if not already in a register).  If that can't be  
implemented, this whole DIP falls apart.

The reason being, that although we want to make it clear the intentions of  
the code (by using the knowingly unsafe addressOf and not &), we don't  
want to penalize code for doing so.  The D compiler and library should be  
neutral on performance, even if it is overly nanny-ish when it comes to  
safety.

-Steve
Feb 06 2013
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 2/6/13, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:

 Probably it'll need a fair amount of tweaking. Anyhow it's in
 destroyable form.
 http://wiki.dlang.org/DIP25


Originally I thought addressOf was only planned for safe functions,
but for system too?
This will likely break almost every library in existence. And
interfacing with C will become severely handicapped.

Btw, using pointers can actually lead to code which is clearer in its intention:

void foo(int* x, int* y) { }
void test(int x, int y)
{
    foo(&x, &y);  // we know foo might modify these parameters
}

Since we don't have "ref" at the call site, using ref parameters can
lead to code which isn't immediately understood at the call site:

void foo(ref int x, ref int y) { }
void test(int x, int y)
{
    foo(x, y);  // can the parameters be modified? it's not clear from
the call site
}

Also the DIP argues that addressOf solves the  property issue w.r.t.
return values. I've proposed we use an .addressOf property which only
works on  property functions, and I saw no arguments against it.
Feb 06 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/6/13 3:02 PM, Andrej Mitrovic wrote:

 On 2/6/13, Andrei Alexandrescu<SeeWebsiteForEmail erdani.org>  wrote:

 Probably it'll need a fair amount of tweaking. Anyhow it's in
 destroyable form.
 http://wiki.dlang.org/DIP25


 Originally I thought addressOf was only planned for safe functions,
 but for system too?
 This will likely break almost every library in existence. And
 interfacing with C will become severely handicapped.


That's a good point.


 Btw, using pointers can actually lead to code which is clearer in its
intention:

 void foo(int* x, int* y) { }
 void test(int x, int y)
 {
      foo(&x,&y);  // we know foo might modify these parameters
 }

 Since we don't have "ref" at the call site, using ref parameters can
 lead to code which isn't immediately understood at the call site:

 void foo(ref int x, ref int y) { }
 void test(int x, int y)
 {
      foo(x, y);  // can the parameters be modified? it's not clear from
 the call site
 }


I think there's no way to have it both ways. You'll have to get used to 
the new style and make it a requirement instead of a stylistic 
preference. Pointers are what they are, and they're not appropriate for 
code that offers guarantees. We could define a bunch of special rules 
for pointers in  safe mode, but I think it's cleaner this way: ref is 
for safe code, if you want to mess with things use pointers.


 Also the DIP argues that addressOf solves the  property issue w.r.t.
 return values. I've proposed we use an .addressOf property which only
 works on  property functions, and I saw no arguments against it.


There aren't, but a library approach is better than a magic work, all 
other things being equal.


Andrei
Feb 06 2013
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 2/6/13, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:

 Pointers are what they are, and they're not appropriate for
 code that offers guarantees.


But we're talking about  system here. I would probably be fine with
these rules if they only applied to  safe.

I feel like someone is trying to put training wheels on my mountain bike.
Feb 06 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/6/2013 4:23 PM, Andrej Mitrovic wrote:

 On 2/6/13, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:

 Pointers are what they are, and they're not appropriate for
 code that offers guarantees.


 But we're talking about  system here. I would probably be fine with
 these rules if they only applied to  safe.

 I feel like someone is trying to put training wheels on my mountain bike.


One reason why  safe is not the default.
Feb 06 2013
parent Marco Leise <Marco.Leise gmx.de> writes:
Am Wed, 06 Feb 2013 22:11:40 -0800
schrieb Walter Bright <newshound2 digitalmars.com>:


 On 2/6/2013 4:23 PM, Andrej Mitrovic wrote:

 On 2/6/13, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:

 Pointers are what they are, and they're not appropriate for
 code that offers guarantees.


 But we're talking about  system here. I would probably be fine with
 these rules if they only applied to  safe.

 I feel like someone is trying to put training wheels on my mountain bike.


 
 One reason why  safe is not the default.


It would also be very very nice, if we could at least write
"Hello, world!" in  safe D.

-- 
Marco
Feb 10 2013
prev sibling parent "Tove" <tove fransson.se> writes:
On Wednesday, 6 February 2013 at 21:40:00 UTC, Andrei 
Alexandrescu wrote:

 On 2/6/13 3:02 PM, Andrej Mitrovic wrote:

 Also the DIP argues that addressOf solves the  property issue 
 w.r.t.
 return values. I've proposed we use an .addressOf property 
 which only
 works on  property functions, and I saw no arguments against 
 it.


 There aren't, but a library approach is better than a magic 
 work, all other things being equal.


 Andrei


struct S
{
    property int var();
    property void var(int);
}

The .addressOf property gave me the idea of solving the 
getter/setter issue, by having two properties...

var.getter
var.setter

maybe it could be added to your library approach though?
Feb 10 2013
prev sibling next sibling parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Wednesday, 6 February 2013 at 07:38:17 UTC, Andrei 
Alexandrescu wrote:

 Probably it'll need a fair amount of tweaking. Anyhow it's in 
 destroyable form.

 http://wiki.dlang.org/DIP25


 Thanks,

 Andrei


I'm not sure why it's trying to safe-up pointers.

Disallowing the & operator on stack variables is going to cause 
code breakage of unprecedented proportions (probably biggest 
since strings where made immutable), I know I use it a LOT in my 
projects, particularly when interfacing with C libraries or 
making slices to stack memory. Also, shoving the burden of 
performance onto the GC for the common case seems like a 
particularly bad choice considering the current state of the art. 
Pointers are relatively rare in D; when users take the address of 
a local variable, it's for a good reason.
Feb 06 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/6/13 5:26 PM, Jakob Ovrum wrote:

 On Wednesday, 6 February 2013 at 07:38:17 UTC, Andrei Alexandrescu wrote:

 Probably it'll need a fair amount of tweaking. Anyhow it's in
 destroyable form.

 http://wiki.dlang.org/DIP25


 Thanks,

 Andrei


 I'm not sure why it's trying to safe-up pointers.

 Disallowing the & operator on stack variables is going to cause code
 breakage of unprecedented proportions (probably biggest since strings
 where made immutable), I know I use it a LOT in my projects,
 particularly when interfacing with C libraries or making slices to stack
 memory. Also, shoving the burden of performance onto the GC for the
 common case seems like a particularly bad choice considering the current
 state of the art. Pointers are relatively rare in D; when users take the
 address of a local variable, it's for a good reason.


I think it stands to reason that we should pull back a little bit and 
only tighten that particular screw in  safe code.

Andrei
Feb 06 2013
prev sibling next sibling parent reply Robert <jfanatiker gmx.at> writes:
What happened to the scope storage class for parameters.

Wouldn't this solve the problems, with the simple rule that you are not
allowed to pass transient objects by reference if the parameter was not
declared with scope? And if I understood correctly, the compiler is
already capable of locally ensuring that the address does not escape (to
ensure the scope requirement), so we are all set?

Maybe even simpler, so that the approach also works with variadic
template functions: All ref/pointer parameters of a trusted/safe method
are automatically scope. 

For the addressOf method, I think it would be needed far too often.
Think about std.stdio.readf() for example. It would really be annoying.

Best regards, 

Robert

On Wed, 2013-02-06 at 02:38 -0500, Andrei Alexandrescu wrote:

 Probably it'll need a fair amount of tweaking. Anyhow it's in 
 destroyable form.
 
 http://wiki.dlang.org/DIP25
 
 
 Thanks,
 
 Andrei
Feb 06 2013
parent reply Johannes Pfau <nospam example.com> writes:
Am Wed, 06 Feb 2013 23:45:51 +0100
schrieb Robert <jfanatiker gmx.at>:


 What happened to the scope storage class for parameters.
 
 Wouldn't this solve the problems, with the simple rule that you are
 not allowed to pass transient objects by reference if the parameter
 was not declared with scope? And if I understood correctly, the
 compiler is already capable of locally ensuring that the address does
 not escape (to ensure the scope requirement), so we are all set?


This is an important question. How would this new proposal interact with
scope parameters?

Scope parameters could at least:
* Allow some otherwise trusted code to be safe:
---------
 trusted bool parse1(ref double v) {
    // Use C's scanf
    return scanf("%f", addressOf(v)) == 1; // Fine
}
---------
can be  safe if scanf parameters are scope parameters. Ditto for the
parse2 example with addressOf.

* Taking the address of a stack variable or a ref parameter could be
  allowed and  safe as long as it's only passed as scope parameters.
  (All examples in "Taking address" could work if scanf were using
  scope parameters)


IIRC the main problem with scope parameters was that escape analysis
isn't implemented yet.
http://d.puremagic.com/issues/show_bug.cgi?id=6931
Feb 06 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 7 February 2013 at 07:41:57 UTC, Johannes Pfau wrote:

 Am Wed, 06 Feb 2013 23:45:51 +0100
 schrieb Robert <jfanatiker gmx.at>:


 What happened to the scope storage class for parameters.
 
 Wouldn't this solve the problems, with the simple rule that 
 you are
 not allowed to pass transient objects by reference if the 
 parameter
 was not declared with scope? And if I understood correctly, the
 compiler is already capable of locally ensuring that the 
 address does
 not escape (to ensure the scope requirement), so we are all 
 set?


 This is an important question. How would this new proposal 
 interact with
 scope parameters?


scope in not enough, as you can alias parameters (for instance 
swap).
Feb 07 2013
parent Johannes Pfau <nospam example.com> writes:
Am Thu, 07 Feb 2013 09:04:29 +0100
schrieb "deadalnix" <deadalnix gmail.com>:


 On Thursday, 7 February 2013 at 07:41:57 UTC, Johannes Pfau wrote:

 Am Wed, 06 Feb 2013 23:45:51 +0100
 schrieb Robert <jfanatiker gmx.at>:


 What happened to the scope storage class for parameters.
 
 Wouldn't this solve the problems, with the simple rule that 
 you are
 not allowed to pass transient objects by reference if the 
 parameter
 was not declared with scope? And if I understood correctly, the
 compiler is already capable of locally ensuring that the 
 address does
 not escape (to ensure the scope requirement), so we are all 
 set?


 This is an important question. How would this new proposal 
 interact with
 scope parameters?


 
 scope in not enough, as you can alias parameters (for instance 
 swap).


Can you give an example?

I understand the scope is not enough to completely replace the rules in
the proposal, but shouldn't it be legal to pass addresses of stack
variables in  safe code as a scope parameter? Could this cause issues
as well?
Feb 07 2013
prev sibling next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 6 February 2013 at 07:38:17 UTC, Andrei 
Alexandrescu wrote:

 Probably it'll need a fair amount of tweaking. Anyhow it's in 
 destroyable form.

 http://wiki.dlang.org/DIP25


 Thanks,


Seems like a good DIP overall.

The limitation on address taking seriously impair the possibility 
of implementing  property properly to emulate a field.

It seems like a solvable problem, as scope can be explicited. But 
then, some address taking are back, and so the syntax problem 
around previous DIP isn't solved (But that is arguably a good 
thing as we should solve problems themselves, not symptoms).
Feb 06 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/6/2013 7:30 PM, deadalnix wrote:

 The limitation on address taking seriously impair the possibility of
 implementing  property properly to emulate a field.


Properties are always going to be subsets of fields. For example,

      property int foo() { return 3; }

is never going to work with trying to get the address of 3. Trying to make it 
work would be a quixotic quest of dubious utility. I.e. I disagree that it is a 
serious impairment.



 It seems like a solvable problem, as scope can be explicited. But then, some
 address taking are back, and so the syntax problem around previous DIP isn't
 solved (But that is arguably a good thing as we should solve problems
 themselves, not symptoms).


The only time (now) that you can take the address of function return value is
if 
that is a return by ref. So, if taking the address of a ref is disallowed, then 
the syntax is no longer ambiguous.
Feb 06 2013
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 7 February 2013 at 06:06:56 UTC, Walter Bright wrote:

 On 2/6/2013 7:30 PM, deadalnix wrote:

 The limitation on address taking seriously impair the 
 possibility of
 implementing  property properly to emulate a field.


 Properties are always going to be subsets of fields. For 
 example,

      property int foo() { return 3; }

 is never going to work with trying to get the address of 3. 
 Trying to make it work would be a quixotic quest of dubious 
 utility. I.e. I disagree that it is a serious impairment.


Obviously it is not going to work in that case.

You'll find a huge difference between it will not work in case 
XXX and it is impossible to make it work.

It is a given that  properties can't 100M emulate field, but the 
goal should be to close he gap as much as possible.


 It seems like a solvable problem, as scope can be explicited. 
 But then, some
 address taking are back, and so the syntax problem around 
 previous DIP isn't
 solved (But that is arguably a good thing as we should solve 
 problems
 themselves, not symptoms).


 The only time (now) that you can take the address of function 
 return value is if that is a return by ref. So, if taking the 
 address of a ref is disallowed, then the syntax is no longer 
 ambiguous.


It doesn't change anything in many cases. Especially for template 
alias parameters. It doesn't change the intrinsic complexity of 
the proposal that conflate a function (as first class object), 
its return value, and the useless C/C++ entity that is a function.
Feb 06 2013
next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 7 February 2013 at 06:13:44 UTC, deadalnix wrote:

 It doesn't change anything in many cases. Especially for 
 template alias parameters. It doesn't change the intrinsic 
 complexity of the proposal that conflate a function (as first 
 class object), its return value, and the useless C/C++ entity 
 that is a function.


Reformulating : it helps on the grammatical perspective, but the
semantic is still broken.
Feb 06 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/6/2013 10:13 PM, deadalnix wrote:

 It is a given that  properties can't 100M emulate field, but the goal should be
 to close he gap as much as possible.


Ok, why should "as much as possible" be the goal? There are other
considerations 
- what merit should they have?

For example, I consider having an easily understood mental model of how things 
work to be very important. Having the language doing mysterious heroic things 
under the hood trying to implement someone else's idea of human intuition 
impairs anyone's ability to understand a language.



 It doesn't change anything in many cases. Especially for template alias
 parameters.


Why? foo seems straightforward as a template alias parameter, meaning the 
function foo. Alias parameters do not take expressions as arguments - so the 
expression rules do not apply.



 It doesn't change the intrinsic complexity of the proposal that
 conflate a function (as first class object), its return value, and the useless
 C/C++ entity that is a function.


Removing an ambiguous case does reduce the intrinsic complexity.
Feb 06 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 7 February 2013 at 06:23:10 UTC, Walter Bright wrote:

 On 2/6/2013 10:13 PM, deadalnix wrote:

 It is a given that  properties can't 100M emulate field, but 
 the goal should be
 to close he gap as much as possible.


 Ok, why should "as much as possible" be the goal? There are 
 other considerations - what merit should they have?


I don't think anyone have interest to get back on that. If you 
have another answer to that question, please share.


 For example, I consider having an easily understood mental 
 model of how things work to be very important. Having the 
 language doing mysterious heroic things under the hood trying 
 to implement someone else's idea of human intuition impairs 
 anyone's ability to understand a language.


Ease come from 2 main things :
  - Fit the mental model that an user have in realted area (ie 
other programing languages)
  - Simplicity (which is very different from ease).

The current proposal seems easy to you because it is close o YOUR 
mental model, working on D. But on a larger scale, it fails at 
both criteria mentioned above : it is different from what exists 
in any languages mentioned in this NG, and a same identifier can 
refers to 3 different distinct (however related) concepts.

DIP25 aim to solve the ref issue. Which is clearly useful. 
Conflating that goal with making previous DIP on function call is 
only going to export the mess in another area of the language.

This is the very example of why simplicity in semantic is key.


 It doesn't change anything in many cases. Especially for 
 template alias
 parameters.


 Why? foo seems straightforward as a template alias parameter, 
 meaning the function foo. Alias parameters do not take 
 expressions as arguments - so the expression rules do not apply.


An alias template parameter bind to a symbol. A symbol can be 
either a first-class function or a the other entity that have no 
name (the symbol resulting of a function declaration).


 It doesn't change the intrinsic complexity of the proposal that
 conflate a function (as first class object), its return value, 
 and the useless
 C/C++ entity that is a function.


 Removing an ambiguous case does reduce the intrinsic complexity.


I'm sure that, as a developer that specialized itself in 
compilers, you perfectly know the difference between syntax and 
semantic. And that solving a syntax issue that is symptom of a 
semantic issue will not fix the semantic issue.
Feb 07 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/7/2013 12:22 AM, deadalnix wrote:

 Ok, why should "as much as possible" be the goal? There are other
 considerations - what merit should they have?


 I don't think anyone have interest to get back on that. If you have another
 answer to that question, please share.



The point is, there must always be a balance of competing interests. That's 
certainly true here.




 For example, I consider having an easily understood mental model of how things
 work to be very important. Having the language doing mysterious heroic things
 under the hood trying to implement someone else's idea of human intuition
 impairs anyone's ability to understand a language.


 Ease come from 2 main things :
   - Fit the mental model that an user have in realted area (ie other programing
 languages)
   - Simplicity (which is very different from ease).

 The current proposal seems easy to you because it is close o YOUR mental model,
 working on D. But on a larger scale, it fails at both criteria mentioned above
:
 it is different from what exists in any languages mentioned in this NG,



know, but I'd be surprised if it did.



 and a same identifier can refers to 3 different distinct (however related)
concepts.


It is not unusual for an identifier to mean different things in different 
constructs.



 DIP25 aim to solve the ref issue. Which is clearly useful. Conflating that goal
 with making previous DIP on function call is only going to export the mess in
 another area of the language.

 This is the very example of why simplicity in semantic is key.


Simplicity is great, but it does not always trump everything else. It's also 
possible for reasonable people to disagree on what is simple or intuitive.




 It doesn't change anything in many cases. Especially for template alias
 parameters.


 Why? foo seems straightforward as a template alias parameter, meaning the
 function foo. Alias parameters do not take expressions as arguments - so the
 expression rules do not apply.


 An alias template parameter bind to a symbol. A symbol can be either a
 first-class function


Yes.


 or a the other entity that have no name (the symbol resulting of a function
declaration).


Yes. But I don't see the issue. &foo cannot bind to an alias parameter, nor can 
foo().



 It doesn't change the intrinsic complexity of the proposal that
 conflate a function (as first class object), its return value, and the useless
 C/C++ entity that is a function.


 Removing an ambiguous case does reduce the intrinsic complexity.


 I'm sure that, as a developer that specialized itself in compilers, you
 perfectly know the difference between syntax and semantic. And that solving a
 syntax issue that is symptom of a semantic issue will not fix the semantic
issue.


What &foo means is a semantic issue, not a syntactic one. It's not an ambiguous 
grammar. Semantic ambiguity issues are resolved by creating rules (which one
may 
consider intuitive or arbitrary) and applying them, which is what we're doing
here.

There are several such ambiguities in D that are resolved by applying semantic 
disambiguation rules. This is done because although it makes the spec (and the 
compiler) more complex, it is actually simpler for the user.

Saying that one cannot take the address of a return value solves the semantic 
ambiguity problem with &foo.
Feb 07 2013
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 7 February 2013 at 09:23:20 UTC, Walter Bright wrote:

 The point is, there must always be a balance of competing 
 interests. That's certainly true here.


That is an assertion not an argument.



 value? I don't know, but I'd be surprised if it did.



consider the whole stuff without the address problem, the D way 

cause syntax problem issue with address of, where D does.


 and a same identifier can refers to 3 different distinct 
 (however related) concepts.


 It is not unusual for an identifier to mean different things in 
 different constructs.


Usually not when they resolve to the same symbol. And it has to 
be proven that this is a good thing.


 Simplicity is great, but it does not always trump everything 
 else. It's also possible for reasonable people to disagree on 
 what is simple or intuitive.


Here we have a more complex solution, and more problem with it. 
Conclude whatever you want, but each time I choose the complex 
path in my programmer life, I ended up with that kind of effect.

You also seems to conflate simple and intuitive, which are really 
unrelated. Simplicity is mostly objective, when intuition is 
mostly subjective. Both combined usually lead to ease.


 Yes.


 or a the other entity that have no name (the symbol resulting 
 of a function declaration).


 Yes. But I don't see the issue. &foo cannot bind to an alias 
 parameter, nor can foo().


void function() foo can.


 What &foo means is a semantic issue, not a syntactic one. It's 
 not an ambiguous grammar. Semantic ambiguity issues are 
 resolved by creating rules (which one may consider intuitive or 
 arbitrary) and applying them, which is what we're doing here.


You should hear ambiguous as ambiguous for the parser here. This 
is possible to make any crazy insane syntax unambiguous for the 
parser.


 There are several such ambiguities in D that are resolved by 
 applying semantic disambiguation rules. This is done because 
 although it makes the spec (and the compiler) more complex, it 
 is actually simpler for the user.


I don't think it is, and looking at other languages choices, I'm 
not alone.

This kind of thing always seems simple of some cases, but ends up 
creating a huge minefield of special case when you start to 
combine feature together. And this is something that most D users 
experiences.

It result in users not using advanced D features (see HIGGS topic 
for instance, or many codebases on github in general) or user 
having trouble. It is often advised to stay away form advanced 
features of D for production quality stuff and I have to say I 
share the observation. Working on large codebase (well large . . 
. for a personal project, but clearly ridiculous compared to many 
companies codebase : ~25 000LOC) using advanced features of D, I 
run in such troubles almost on a daily basis, and have developed 
some knowledge of area of the language I should not even try to 
go in.
Feb 07 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/7/2013 2:05 AM, deadalnix wrote:

 On Thursday, 7 February 2013 at 09:23:20 UTC, Walter Bright wrote:

 The point is, there must always be a balance of competing interests. That's
 certainly true here.


 That is an assertion not an argument.


Try designing anything by using one overriding principle - you won't get a 
useful result. Designs are always tradeoffs, always.




 know, but I'd be surprised if it did.






It's a different language, with a different view of things. Direct comparisons 





of,
 where D does.


I don't understand this sentence.



 and a same identifier can refers to 3 different distinct (however related)
 concepts.


 It is not unusual for an identifier to mean different things in different
 constructs.


 Usually not when they resolve to the same symbol. And it has to be proven that
 this is a good thing.


How does one prove anything is a "good thing"?



 Simplicity is great, but it does not always trump everything else. It's also
 possible for reasonable people to disagree on what is simple or intuitive.


 Here we have a more complex solution, and more problem with it. Conclude
 whatever you want, but each time I choose the complex path in my programmer
 life, I ended up with that kind of effect.

 You also seems to conflate simple and intuitive,


Not really, I said "simple OR intuitive" :-)



 Yes. But I don't see the issue. &foo cannot bind to an alias parameter, nor
 can foo().


 void function() foo can.


Sure. But I'm lost at what your point is with that example.



 There are several such ambiguities in D that are resolved by applying semantic
 disambiguation rules. This is done because although it makes the spec (and the
 compiler) more complex, it is actually simpler for the user.


 I don't think it is, and looking at other languages choices, I'm not alone.


Given the vast variety and complexity of languages out there, for every example 
of A you can find, I can find examples of !A. It's not really useful, after
all, 
if other languages got it all right, there's no point to D.



 This kind of thing always seems simple of some cases, but ends up creating a
 huge minefield of special case when you start to combine feature together. And
 this is something that most D users experiences.


I believe that Andrei's proposal resolves these.



 It result in users not using advanced D features (see HIGGS topic for instance,
 or many codebases on github in general) or user having trouble. It is often
 advised to stay away form advanced features of D for production quality stuff
 and I have to say I share the observation. Working on large codebase (well
large
 . . . for a personal project, but clearly ridiculous compared to many companies
 codebase : ~25 000LOC) using advanced features of D, I run in such troubles
 almost on a daily basis, and have developed some knowledge of area of the
 language I should not even try to go in.


This is exactly why we're going through this exercise with the properties.
Feb 07 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 7 February 2013 at 10:32:38 UTC, Walter Bright wrote:

 On 2/7/2013 2:05 AM, deadalnix wrote:

 On Thursday, 7 February 2013 at 09:23:20 UTC, Walter Bright 
 wrote:

 The point is, there must always be a balance of competing 
 interests. That's
 certainly true here.


 That is an assertion not an argument.


 Try designing anything by using one overriding principle - you 
 won't get a useful result. Designs are always tradeoffs, always.


Ho yeah, I'm not arguing against that. But what is seen as 
conflicting goal often aren't.



 value? I don't
 know, but I'd be surprised if it did.



 you consider the
 whole stuff without the address problem, the D way is 



 It's a different language, with a different view of things. 

 account.




 issue with address of,
 where D does.


 I don't understand this sentence.



what is called in D a delegate. foo.bar() execute that delegate.

It remove the need for &foo.bar altogether, so with that 
mechanism in D, no problem with & operator.

Scala does even one step further by executing the method, or not, 
depending on what is expected, proving that optional () are 
compatible with.

Back to D, we have void function() foo; foo is declared as a 
function here. However, void bar() {} will also be called a 
function, even if the entity represented by foo and bar are 
completely different.

When you do foo = &bar, you get a pointer on foo's instruction. 
Here foo isn't a function in the D sense, but an Array of CPU 
instruction, or something like that. This entity, coming from 
C/C++ hasn't ANY useful usage except taking the address of to get 
a function. Wanting to keep that useless entity is the source of 
most trouble with the & syntax, and also on previous DIP (not 
that one).


 How does one prove anything is a "good thing"?


Proven may be strong, but you can't refute that some things are 
better than others.


 Yes. But I don't see the issue. &foo cannot bind to an alias 
 parameter, nor
 can foo().


 void function() foo can.


 Sure. But I'm lost at what your point is with that example.


Now you can pass several object to templates alias parameters, 
that will behave differently in slightly different subtle ways. 
For no real good reason.


 I don't think it is, and looking at other languages choices, 
 I'm not alone.


 Given the vast variety and complexity of languages out there, 
 for every example of A you can find, I can find examples of !A. 
 It's not really useful, after all, if other languages got it 
 all right, there's no point to D.


If A is the instruction pack entity type mentionned above, you'll 
find pretty hard to find a !A if we exclude C and C++ (well and 
D, but it is kind of excluded if look for references). I don't 
pretend none exists, but it seems pretty hard to find one.

Because the idea is bad for everybody : it make the language more 
complex, harder to implement compiler/tooling for, can conflict 
with other features, and worse, have no benefice.

This is a bad idea in all possible way. Actually so bad that even 
PHP don't implement it.


 This kind of thing always seems simple of some cases, but ends 
 up creating a
 huge minefield of special case when you start to combine 
 feature together. And
 this is something that most D users experiences.


 I believe that Andrei's proposal resolves these.


He does so by adding special cases. That is the problem with 
special cases, they multiply themselves faster than rabbits.


 It result in users not using advanced D features (see HIGGS 
 topic for instance,
 or many codebases on github in general) or user having 
 trouble. It is often
 advised to stay away form advanced features of D for 
 production quality stuff
 and I have to say I share the observation. Working on large 
 codebase (well large
 . . . for a personal project, but clearly ridiculous compared 
 to many companies
 codebase : ~25 000LOC) using advanced features of D, I run in 
 such troubles
 almost on a daily basis, and have developed some knowledge of 
 area of the
 language I should not even try to go in.


 This is exactly why we're going through this exercise with the 
 properties.


It is clear that the property improvement proposed by Andrei is a 
great step forward. However, the &foo.bar that return the 
delegate when bar is a property is exactly the kind of stuff that 
are waiting to explode.

Yes, this DIP remove the syntactic ambiguity (does this take the 
delegate or the address of the result ?) but that is barely it. 
I'd say that the fact that & have a meaning is way more 
problematic than the fact that it is not possible to take the 
resulting address.
Feb 07 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/7/2013 3:16 AM, deadalnix wrote:


 of,
 where D does.


 I don't understand this sentence.



 D a delegate. foo.bar() execute that delegate.

 It remove the need for &foo.bar altogether, so with that mechanism in D, no
 problem with & operator.

 Scala does even one step further by executing the method, or not, depending on
 what is expected, proving that optional () are compatible with.

 Back to D, we have void function() foo; foo is declared as a function here.


No, that declares foo as a "pointer to function".



 Now you can pass several object to templates alias parameters, that will behave
 differently in slightly different subtle ways. For no real good reason.


They won't behave any differently than they would outside of being passed as 
aliases. I don't see a special problem added with alias parameters.



 I don't think it is, and looking at other languages choices, I'm not alone.


 Given the vast variety and complexity of languages out there, for every
 example of A you can find, I can find examples of !A. It's not really useful,
 after all, if other languages got it all right, there's no point to D.


 If A is the instruction pack entity type mentionned above, you'll find pretty
 hard to find a !A if we exclude C and C++ (well and D, but it is kind of
 excluded if look for references). I don't pretend none exists, but it seems
 pretty hard to find one.


There are few languages in the systems programming category (languages that
give 
one full access to pointers), so excluding C and C++ seems rather draconian.



 He does so by adding special cases. That is the problem with special cases,
they
 multiply themselves faster than rabbits.


Taking the address of a ref was already problematic.
Feb 07 2013
parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 7 February 2013 at 19:57:50 UTC, Walter Bright wrote:

 On 2/7/2013 3:16 AM, deadalnix wrote:


 issue with address
 of,
 where D does.


 I don't understand this sentence.



 what is called in
 D a delegate. foo.bar() execute that delegate.

 It remove the need for &foo.bar altogether, so with that 
 mechanism in D, no
 problem with & operator.

 Scala does even one step further by executing the method, or 
 not, depending on
 what is expected, proving that optional () are compatible with.

 Back to D, we have void function() foo; foo is declared as a 
 function here.


 No, that declares foo as a "pointer to function".


That isn't what I read. It is clearly written void function() 
foo; And if in int a; a is an int and in int* b, b is a pointer 
on int, foo must be a function. The fact that this very entity 
type is called function pointer is C is irrelevant.

The distinction between the 2 is a problem in the first place, as 
it create new entities with different behavior, for a benefice 
that is unclear to me.


 Now you can pass several object to templates alias parameters, 
 that will behave
 differently in slightly different subtle ways. For no real 
 good reason.


 They won't behave any differently than they would outside of 
 being passed as aliases. I don't see a special problem added 
 with alias parameters.


Because the same syntax have different meanings, so suddenly, you 
have to special case everything. That is never done in practice, 
not even in phobos.


 If A is the instruction pack entity type mentionned above, 
 you'll find pretty
 hard to find a !A if we exclude C and C++ (well and D, but it 
 is kind of
 excluded if look for references). I don't pretend none exists, 
 but it seems
 pretty hard to find one.


 There are few languages in the systems programming category 
 (languages that give one full access to pointers), so excluding 
 C and C++ seems rather draconian.


I don't see why this should be limited to system languages. This 
is about function and most languages have functions (and most 
modern languages have first class functions).


language often do not conflict with pointer access.


 He does so by adding special cases. That is the problem with 
 special cases, they
 multiply themselves faster than rabbits.


 Taking the address of a ref was already problematic.


Yes indeed. I never argued against that.
Feb 07 2013
prev sibling parent reply "Zach the Mystic" <reachBUTMINUSTHISzach gOOGLYmail.com> writes:
On Thursday, 7 February 2013 at 09:23:20 UTC, Walter Bright wrote:

 DIP25 aim to solve the ref issue. Which is clearly useful. 
 Conflating that goal
 with making previous DIP on function call is only going to 
 export the mess in
 another area of the language.

 This is the very example of why simplicity in semantic is key.


 Simplicity is great, but it does not always trump everything 
 else. It's also possible for reasonable people to disagree on 
 what is simple or intuitive.


Can you tell me if you consider my proposal with regard to making 
ref safe and complete simple and intuitive both for compiler and 
user, and if not, why? (I don't have an opinion about '&' yet.)

http://forum.dlang.org/thread/ket199$2c27$1 digitalmars.com#post-bsgrtofehxfjmzkaedfr:40forum.dlang.org
Feb 07 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/7/2013 6:15 AM, Zach the Mystic wrote:

 Can you tell me if you consider my proposal with regard to making ref safe and
 complete simple and intuitive both for compiler and user, and if not, why? (I
 don't have an opinion about '&' yet.)

 http://forum.dlang.org/thread/ket199$2c27$1 digitalmars.com#post-bsgrtofehxfjmzkaedfr:40forum.dlang.org


I don't know if it's complete and safe. It's not something that can be 
determined with a quick read.
Feb 07 2013
parent "Zach the Mystic" <reachBUTMINUSTHISzach gOOGLYmail.com> writes:
On Thursday, 7 February 2013 at 19:49:27 UTC, Walter Bright wrote:

 On 2/7/2013 6:15 AM, Zach the Mystic wrote:

 Can you tell me if you consider my proposal with regard to 
 making ref safe and
 complete simple and intuitive both for compiler and user, and 
 if not, why? (I
 don't have an opinion about '&' yet.)

 http://forum.dlang.org/thread/ket199$2c27$1 digitalmars.com#post-bsgrtofehxfjmzkaedfr:40forum.dlang.org


 I don't know if it's complete and safe. It's not something that 
 can be determined with a quick read.


Okay. But at least that's a 'check' on simple and intuitive?

As far as why I think it's safe, my investigation led me to 
conclude that the key question was, how do I know whether to 
treat the return value of a ref function which accept a ref as 
local or global? I pass a value into a mysterious box, how do I 
know whether what comes out the other end is related to what I 
passed in, or something completely different? All the cases DIP25 
takes care of are the ones which can be known just by the 
peculiarities of the call and signature, but many cases just 
leave you in the dark. The only way the compiler can know for 
sure without help from the function signature is by dipping into 
the function's code to take a look, which seems like too high a 
price to pay. About a month ago Jonathan M Davis brought this up 
and pointed out that the PIMPL idiom occasionally banishes 
altogether that opportunity for the compiler.

After a few tries, I realized that 'out' was actually still 
available to use for this purpose, which is either pure luck 
(possible) or a hidden byproduct of the fact that 1) it's a good 
keyword to begin with or 2) there's a secret truth to its 
interchangeability with 'ref' which applies to return values as 
well as to parameter tags.
Feb 07 2013
prev sibling next sibling parent Robert <jfanatiker gmx.at> writes:
The solution to this problem has been posted already many times, simply
allow fields to be marked with  property too, having the compiler lower
it to a private field with trivial setter/getter method.

As I already mentioned, I don't really see the point of properties at
all, if they are not interchangeable with fields. We could as well use
setXXX/getXXX as in Java.

On Wed, 2013-02-06 at 22:06 -0800, Walter Bright wrote:

 Properties are always going to be subsets of fields. For example,
 
       property int foo() { return 3; }
 
 is never going to work with trying to get the address of 3. Trying to
 make it 
 work would be a quixotic quest of dubious utility. I.e. I disagree
 that it is a 
 serious impairment.
Feb 07 2013
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 07 Feb 2013 01:06:34 -0500, Walter Bright  
<newshound2 digitalmars.com> wrote:


 The only time (now) that you can take the address of function return  
 value is if that is a return by ref. So, if taking the address of a ref  
 is disallowed, then the syntax is no longer ambiguous.


Thinking about this, I don't know that I like the idea of disallowing  
taking the address of ref.

One major usage of taking the address of ref returns is the opIndex  
operator:

int *ptr = &arr[0];

Or, more generally, the front property of a range:

int *ptr = &arr.front;

What I am concerned about is that this is not going to have the desired  
effect.  Instead of grudgingly switching to a new style of coding, people  
will simply return pointers instead of ref.

-Steve
Feb 07 2013
parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 7 February 2013 at 14:43:38 UTC, Steven 
Schveighoffer wrote:

 On Thu, 07 Feb 2013 01:06:34 -0500, Walter Bright 
 <newshound2 digitalmars.com> wrote:


 The only time (now) that you can take the address of function 
 return value is if that is a return by ref. So, if taking the 
 address of a ref is disallowed, then the syntax is no longer 
 ambiguous.


 Thinking about this, I don't know that I like the idea of 
 disallowing taking the address of ref.

 One major usage of taking the address of ref returns is the 
 opIndex operator:

 int *ptr = &arr[0];

 Or, more generally, the front property of a range:

 int *ptr = &arr.front;

 What I am concerned about is that this is not going to have the 
 desired effect.  Instead of grudgingly switching to a new style 
 of coding, people will simply return pointers instead of ref.


Exactly.
Feb 07 2013
prev sibling next sibling parent reply Marco Leise <Marco.Leise gmx.de> writes:
Am Wed, 06 Feb 2013 02:38:17 -0500
schrieb Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>:


 Probably it'll need a fair amount of tweaking. Anyhow it's in 
 destroyable form.
 
 http://wiki.dlang.org/DIP25
 
 
 Thanks,
 
 Andrei


At first I was skeptical about how this would work with binary
operator overloads where you have a lot of ref returns.
(Think vector * matrix.) But as it seems, only stack local
variables underly new restrictions. So anything that operates
only on 'this' stays valid code.
I'd still like to see some actual code that will break, since
its bad to rely on lack of imagination and contrived examples.

As for the address taking, I hope it doesn't end up in being
nannied to much by the language. Like in the case with printf,
it could really piss people off that don't understand the
reasoning behind it. Make the error message informative for
that: "Potential escape of pointer to stack local" or
similar.

-- 
Marco
Feb 06 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/6/2013 8:16 PM, Marco Leise wrote:

 As for the address taking, I hope it doesn't end up in being
 nannied to much by the language. Like in the case with printf,
 it could really piss people off that don't understand the
 reasoning behind it. Make the error message informative for
 that: "Potential escape of pointer to stack local" or
 similar.


I think C++ missed an opportunity with reference types. All they are in C++ are 
just another way to express a pointer. They don't really offer any semantic 
improvement - you can even have null references.

In D, we have an opportunity to define reference types as a kind of "safe" 
pointer type - where we can get much of the advantages of pointers without the 
potential for memory corruption.
Feb 06 2013
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Feb 06, 2013 at 10:09:48PM -0800, Walter Bright wrote:

 On 2/6/2013 8:16 PM, Marco Leise wrote:

As for the address taking, I hope it doesn't end up in being
nannied to much by the language. Like in the case with printf,
it could really piss people off that don't understand the
reasoning behind it. Make the error message informative for
that: "Potential escape of pointer to stack local" or
similar.


 
 I think C++ missed an opportunity with reference types. All they are
 in C++ are just another way to express a pointer. They don't really
 offer any semantic improvement - you can even have null references.
 
 In D, we have an opportunity to define reference types as a kind of
 "safe" pointer type - where we can get much of the advantages of
 pointers without the potential for memory corruption.


D ref types are currently highly crippled because of the inability to
declare ref variables, which mandates ugly workarounds. It should be a
first-class type qualifier IMO. (Yes I know it's currently a *function*
qualifier, not a type qualifier... which makes it all the more ugly.)


T

-- 
Дерево держится корнями, а человек -
друзьями.
Feb 06 2013
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/7/13 1:34 AM, H. S. Teoh wrote:

 On Wed, Feb 06, 2013 at 10:09:48PM -0800, Walter Bright wrote:

 On 2/6/2013 8:16 PM, Marco Leise wrote:

 As for the address taking, I hope it doesn't end up in being
 nannied to much by the language. Like in the case with printf,
 it could really piss people off that don't understand the
 reasoning behind it. Make the error message informative for
 that: "Potential escape of pointer to stack local" or
 similar.


 I think C++ missed an opportunity with reference types. All they are
 in C++ are just another way to express a pointer. They don't really
 offer any semantic improvement - you can even have null references.

 In D, we have an opportunity to define reference types as a kind of
 "safe" pointer type - where we can get much of the advantages of
 pointers without the potential for memory corruption.


 D ref types are currently highly crippled because of the inability to
 declare ref variables, which mandates ugly workarounds. It should be a
 first-class type qualifier IMO. (Yes I know it's currently a *function*
 qualifier, not a type qualifier... which makes it all the more ugly.)


Unfortunately type qualifiers have very high complexity costs. I think 
it's very neat that we managed to keep ref the way it is. Yes, I, too, 
would like to have a ref variable sometimes, but overall I'm please with 
the way it's working (post DIP25 especially).

Andrei
Feb 06 2013
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 7 February 2013 at 06:36:22 UTC, H. S. Teoh wrote:

 D ref types are currently highly crippled because of the 
 inability to
 declare ref variables, which mandates ugly workarounds. It 
 should be a
 first-class type qualifier IMO. (Yes I know it's currently a 
 *function*
 qualifier, not a type qualifier... which makes it all the more 
 ugly.)


My heart say yes, but my brain doesn't really any way to make
that work :/
Feb 07 2013
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Wed, 06 Feb 2013 02:38:17 -0500
schrieb Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>:


 Probably it'll need a fair amount of tweaking. Anyhow it's in 
 destroyable form.
 
 http://wiki.dlang.org/DIP25
 
 
 Thanks,
 
 Andrei


Regarding the questions about scope parameters and allowing & in system
code, wouldn't it make sense to change the rules to the following:

* Taking the address in  system code is allowed. You can do everything
  with the returned address just as right now.

* Taking the address in  safe code is also allowed, but you can't do
  anything with it: You can't assign it to anything, can't return it
  and can't dereference it.

** Once full escape analysis and scope parameters are implemented,
   those rule will be relaxed a little and passing such pointers to
   some functions (e.g. as scope parameters) will be allowed in  safe
   code.

** addressOf isn't necessary as you can take addresses in  system code
   anyway 

This makes more sense than disallowing the & operator completely
as we'd have to reintroduce it anyway once scope is implemented. This
way we start with a strict, conservative way and relax the rules when
the compiler can prove that the operations are really safe.
Feb 07 2013
prev sibling next sibling parent reply Chad Joan <chadjoan gmail.com> writes:
On 02/06/2013 02:38 AM, Andrei Alexandrescu wrote:

 Probably it'll need a fair amount of tweaking. Anyhow it's in
 destroyable form.

 http://wiki.dlang.org/DIP25


 Thanks,

 Andrei


A single delegate (closure) can be used to defer both reads and writes 
on an arbitrary expression.

This works on naked variables, references, pointers, properties, and 
probably a number of other things I haven't thought of yet.

Here's the relevance to DIP25: closures already have well-defined escape 
semantics.  The downside is that they probably allocate heap way too 
aggressively in the current implementation.  The upshot is that they are 
always memory-safe.  This makes optimization a quality-of-implementation 
issue: a sufficiently intelligent compiler should be able to remove many 
allocations for non-escaping closures.

Perhaps ref parameters should be delegates under the hood instead of 
pointers?

The longterm disadvantage I see with this is the extra pointer that must 
be passed/returned.  I wonder how hard it would be for the compiler to 
instantiate specialized oldschool-pointer versions of functions with ref 
parameters whenever calls are made that do not require the guarantees 
that closures provide.

A working demonstration is given below.

Destroy!


import std.traits;
import std.stdio;

struct Option(T)
{
     bool hasValue = false;
     union
     {
         ubyte nope;
         T value;
     }

     this( T value )
     {
         hasValue = true;
         this.value = value;
     }
}

Option!T none(T)()
{
     Option!T result;
     return result;
}

/* For some reason we need to cast to this to make template deduction 
work on any functions it gets passed into. */
template DelegateRef(T)
{
     alias T delegate(Option!T intake) DelegateRef;
}

template isDelegateRef(T)
{
     static if ( isDelegate!T )
     {
         alias ReturnType!T R;
         static if ( is( T == R delegate(Option!R) ) )
             enum isDelegateRef = true;
         else
             enum isDelegateRef = false;
     }
     else
         enum isDelegateRef = false;
}

string accessor(string expr)
{
     return
         `cast(DelegateRef!(typeof(`~expr~`))) (`~
         `delegate typeof(`~expr~`)(Option!(typeof(`~expr~`)) intake) {`~
         `    if ( intake.hasValue )`~
         `        return (`~expr~` = intake.value);`~
         `    else`~
         `        return `~expr~`;`~
         `})`;
}

// Function that accepts a reference.
auto someFunc(Q)(Q qux) if ( isDelegateRef!Q )
{
     alias ReturnType!Q T;
     auto x = qux(none!T);
     x |= 0xF00D;
     qux(Option!T(x));
     return qux(none!T);
}

struct MyStruct
{
     private int m_q;

      property int q()
     {
         writefln("get q (%x)",m_q);
         return m_q;
     }

      property int q(int v)
     {
         writefln("set q (%x = %x)", m_q, v);
         return m_q = v;
     }
}

void testRef( ref int foo )
{
     assert(someFunc(mixin(accessor("foo"))) == 0xF00D);
}

void testPtr( int* foo )
{
     assert(someFunc(mixin(accessor("*foo"))) == 0xF00D);
}

void main()
{
     int abc = 0;
     assert(someFunc(mixin(accessor("abc"))) == 0xF00D);
     assert(abc == 0xF00D);

     int foo = 0;
     testRef(foo);
     assert(foo == 0xF00D);

     int bar = 0;
     testPtr(&bar);
     assert(bar == 0xF00D);

     MyStruct s;
     s.q = 0;
     assert(someFunc(mixin(accessor("s.q"))) == 0xF00D);
     assert(s.q == 0xF00D);
}
Feb 07 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Friday, 8 February 2013 at 06:28:54 UTC, Chad Joan wrote:

 On 02/06/2013 02:38 AM, Andrei Alexandrescu wrote:

 Probably it'll need a fair amount of tweaking. Anyhow it's in
 destroyable form.

 http://wiki.dlang.org/DIP25


 Thanks,

 Andrei


 A single delegate (closure) can be used to defer both reads and 
 writes on an arbitrary expression.

 This works on naked variables, references, pointers, 
 properties, and probably a number of other things I haven't 
 thought of yet.

 Here's the relevance to DIP25: closures already have 
 well-defined escape semantics.  The downside is that they 
 probably allocate heap way too aggressively in the current 
 implementation.  The upshot is that they are always 
 memory-safe.  This makes optimization a 
 quality-of-implementation issue: a sufficiently intelligent 
 compiler should be able to remove many allocations for 
 non-escaping closures.

 Perhaps ref parameters should be delegates under the hood 
 instead of pointers?

 The longterm disadvantage I see with this is the extra pointer 
 that must be passed/returned.  I wonder how hard it would be 
 for the compiler to instantiate specialized oldschool-pointer 
 versions of functions with ref parameters whenever calls are 
 made that do not require the guarantees that closures provide.

 A working demonstration is given below.

 Destroy!


The cost of passing a delegate is way higher than the cost of 
passing the extra pointer. Delegate cause an opaque function call 
so :
  - All registers that the callee is allowed to trash must be 
saved preventively (even if the callee don't trash them).
  - CPU cannot really use branch prediction.
  - The compiler must assume that the delegate call may have 
arbitrary side effects so have to commit everything to memory and 
then take everything back afterward. This prevent many 
instruction reordering, register promotions, dead read/write 
elimination, constant propagation and so on.

Considering passing by ref is sometime done to fasten things, 
this defeat the whole point.

Note that the operation above are not dying slow, but clearly not 
a good fit for ref.


 import std.traits;
 import std.stdio;

 struct Option(T)
 {
     bool hasValue = false;
     union
     {
         ubyte nope;
         T value;
     }

     this( T value )
     {
         hasValue = true;
         this.value = value;
     }
 }

 Option!T none(T)()
 {
     Option!T result;
     return result;
 }

 /* For some reason we need to cast to this to make template 
 deduction work on any functions it gets passed into. */
 template DelegateRef(T)
 {
     alias T delegate(Option!T intake) DelegateRef;
 }

 template isDelegateRef(T)
 {
     static if ( isDelegate!T )
     {
         alias ReturnType!T R;
         static if ( is( T == R delegate(Option!R) ) )
             enum isDelegateRef = true;
         else
             enum isDelegateRef = false;
     }
     else
         enum isDelegateRef = false;
 }

 string accessor(string expr)
 {
     return
         `cast(DelegateRef!(typeof(`~expr~`))) (`~
         `delegate typeof(`~expr~`)(Option!(typeof(`~expr~`)) 
 intake) {`~
         `    if ( intake.hasValue )`~
         `        return (`~expr~` = intake.value);`~
         `    else`~
         `        return `~expr~`;`~
         `})`;
 }

 // Function that accepts a reference.
 auto someFunc(Q)(Q qux) if ( isDelegateRef!Q )
 {
     alias ReturnType!Q T;
     auto x = qux(none!T);
     x |= 0xF00D;
     qux(Option!T(x));
     return qux(none!T);
 }

 struct MyStruct
 {
     private int m_q;

      property int q()
     {
         writefln("get q (%x)",m_q);
         return m_q;
     }

      property int q(int v)
     {
         writefln("set q (%x = %x)", m_q, v);
         return m_q = v;
     }
 }

 void testRef( ref int foo )
 {
     assert(someFunc(mixin(accessor("foo"))) == 0xF00D);
 }

 void testPtr( int* foo )
 {
     assert(someFunc(mixin(accessor("*foo"))) == 0xF00D);
 }

 void main()
 {
     int abc = 0;
     assert(someFunc(mixin(accessor("abc"))) == 0xF00D);
     assert(abc == 0xF00D);

     int foo = 0;
     testRef(foo);
     assert(foo == 0xF00D);

     int bar = 0;
     testPtr(&bar);
     assert(bar == 0xF00D);

     MyStruct s;
     s.q = 0;
     assert(someFunc(mixin(accessor("s.q"))) == 0xF00D);
     assert(s.q == 0xF00D);
 }
Feb 07 2013
parent Chad Joan <chadjoan gmail.com> writes:
On 02/08/2013 02:06 AM, deadalnix wrote:

 On Friday, 8 February 2013 at 06:28:54 UTC, Chad Joan wrote:

 Destroy!


 The cost of passing a delegate is way higher than the cost of passing
 the extra pointer. Delegate cause an opaque function call so :
 - All registers that the callee is allowed to trash must be saved
 preventively (even if the callee don't trash them).
 - CPU cannot really use branch prediction.
 - The compiler must assume that the delegate call may have arbitrary
 side effects so have to commit everything to memory and then take
 everything back afterward. This prevent many instruction reordering,
 register promotions, dead read/write elimination, constant propagation
 and so on.

 Considering passing by ref is sometime done to fasten things, this
 defeat the whole point.

 Note that the operation above are not dying slow, but clearly not a good
 fit for ref.


Fair enough.

I wonder if we can learn something from it though.  It does seem to 
provide a conceptual model that's very desirable.
Feb 08 2013
prev sibling next sibling parent "Michael" <pr m1xa.com> writes:
Two more things:

Disable a read/write propa like int getSetSomeInteger(int).
int getSomeInteger() and void setSomeIntger(int) only allowed.

And disable default parameter for setter.
Feb 09 2013
prev sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, February 06, 2013 02:38:17 Andrei Alexandrescu wrote:

 Probably it'll need a fair amount of tweaking. Anyhow it's in
 destroyable form.
 
 http://wiki.dlang.org/DIP25


Overall, the ref part seems good, but I'm highly skeptical of the part on 
addresses.

The main point I'd raise about the ref portion is that module-level variables 
need to be grouped in with the static variables. You seem to have marked some 
module-level variables as scope in the examples, but static has no effect on 
module-level variables.

As for the addresses, it seems very bizarre to create a function for doing 
what & does and then make & legal only in very restricted circumstances. 
Having a safeAddressOf for some set of restricted circumstances might make 
sense, but couldn't the compiler just detect that & was safe under those 
circumstances? If the compiler can determine that it's  safe using the 
function, it should be possible for it to determine it without. And 
disallowing & even in  system code is _way_ overkill. The compiler is already 
able to detect at least some unsafe cases (e.g. taking the address of a local 
variable), and it's incredibly common to need to do some of those when 
interacting with C code (e.g. taking the address of a local variable and 
passing it to a C function).

If the problem is ambiguities between taking the address of a function and the 
address of its return value, then I'd think that it would be much cleaner to 
just create a __trait for getting the address of a function. It's needed far 
less than taking the address of a variable, and the difference between & and 
addressOf is just going to sow confusion. It definitely seems like overkill to 
me to introduce a function for doing what & already does just to deal with the 
difference between taking the address of a function and taking the address of 
its return value.

So, I'm in favor of the changes to ref, but I definitely don't like what this
DIP does with &.

- Jonathan M Davis
Feb 11 2013