February 06, 2013
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
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
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
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
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
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
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
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
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
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