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

February 07, 2013
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
February 07, 2013
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
February 07, 2013
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.
February 07, 2013
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.
February 07, 2013
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.

February 07, 2013
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.
February 07, 2013
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.
February 07, 2013
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.
February 07, 2013
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.