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.

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

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;
}

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.

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

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

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

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.

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.

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).