February 06, 2013 Re: DIP25 draft available for destruction | ||||
---|---|---|---|---|
| ||||
Posted in reply to Benjamin Thaut | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Benjamin Thaut | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Benjamin Thaut | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrej Mitrovic | 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 |
Copyright © 1999-2021 by the D Language Foundation