View mode: basic / threaded / horizontal-split · Log in · Help
February 06, 2013
Re: DIP25 draft available for destruction
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
February 06, 2013
Re: DIP25 draft available for destruction
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
February 06, 2013
Re: DIP25 draft available for destruction
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
February 06, 2013
Re: DIP25 draft available for destruction
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
February 06, 2013
Re: DIP25 draft available for destruction
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.
February 06, 2013
Re: DIP25 draft available for destruction
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
February 06, 2013
Re: DIP25 draft available for destruction
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
February 06, 2013
Re: DIP25 draft available for destruction
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
February 06, 2013
Re: DIP25 draft available for destruction
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.
February 06, 2013
Re: DIP25 draft available for destruction
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
1 2 3 4 5 6
Top | Discussion index | About this forum | D home