On Sunday, 26 May 2013 at 01:47:39 UTC, Andrei Alexandrescu wrote:
> On 5/25/13 9:18 PM, Adam D. Ruppe wrote:
>> On Sunday, 26 May 2013 at 01:12:35 UTC, Andrei Alexandrescu wrote:
>>> On 5/25/13 9:03 PM, Andrej Mitrovic wrote:
>>>> On 5/26/13, Andrei Alexandrescu<SeeWebsiteForEmail@erdani.org>
>>>>> in { auto oldLen = this.length; }
>>>> out { assert(this.length == in.oldLen + 1); }
>>
>>> Since every in.xyz expression could access an arbitrary method of the
>>> old object,
>>
>> Here, in.oldLen refers to the local variable you defined in the in{}
>> scope, as opposed to plain oldLen which would be searing the out{} scope.
>
> Ohh, I see. Yes, that could work.
>
>
> Thanks,
>
> Andrei

Wouldn't it be simpler to define in the `in` clause what to pass to the out clause? Something like:

    class A {
        void fun()
        in { out oldLen = this.length; }
        out { assert(this.length == oldLen + 1); }
        body { ... }
    }

Or even combine the two:

    class A {
        void fun()
        in { out oldLen = this.length; }
        out { assert(this.length == in.oldLen + 1); }
        body { ... }
    }

On Sunday, 26 May 2013 at 00:43:36 UTC, Andrei Alexandrescu wrote:
> That was technically difficult to do back then, and fell by the wayside. Today it would break too much code to introduce even if feasible.
>

Can you expand more on the breakage risk please ?

On Monday, May 27, 2013 09:37:38 deadalnix wrote:
> On Sunday, 26 May 2013 at 00:43:36 UTC, Andrei Alexandrescu wrote:
> > That was technically difficult to do back then, and fell by the wayside. Today it would break too much code to introduce even if feasible.
> 
> Can you expand more on the breakage risk please ?

If nothing else, it would mean that the variables inside of the in block would not go out of scope when the in block ended, so their destructors would not be called and the like, whereas now they would be. The same goes for scope statements in the in block. I don't know how much of an issue any of that is realistically though. But Andrei may have other reasons why it would be a problem.

- Jonathan M Davis

On Monday, 27 May 2013 at 07:42:44 UTC, Jonathan M Davis wrote:
> On Monday, May 27, 2013 09:37:38 deadalnix wrote:
>> On Sunday, 26 May 2013 at 00:43:36 UTC, Andrei Alexandrescu wrote:
>> > That was technically difficult to do back then, and fell by the
>> > wayside. Today it would break too much code to introduce even
>> > if feasible.
>> 
>> Can you expand more on the breakage risk please ?
>
> If nothing else, it would mean that the variables inside of the in block would
> not go out of scope when the in block ended, so their destructors would not be
> called and the like, whereas now they would be. The same goes for scope
> statements in the in block. I don't know how much of an issue any of that is
> realistically though. But Andrei may have other reasons why it would be a
> problem.
>

You are right, destructor is an issue. The risk of name collision exists as well but I don't think it is realistically that widespread in actual codebase.

On Monday, 27 May 2013 at 09:06:58 UTC, deadalnix wrote:
> On Monday, 27 May 2013 at 07:42:44 UTC, Jonathan M Davis wrote:
>> On Monday, May 27, 2013 09:37:38 deadalnix wrote:
>>> On Sunday, 26 May 2013 at 00:43:36 UTC, Andrei Alexandrescu wrote:
>>> > That was technically difficult to do back then, and fell by the
>>> > wayside. Today it would break too much code to introduce even
>>> > if feasible.
>>> 
>>> Can you expand more on the breakage risk please ?
>>
>> If nothing else, it would mean that the variables inside of the in block would
>> not go out of scope when the in block ended, so their destructors would not be
>> called and the like, whereas now they would be. The same goes for scope
>> statements in the in block. I don't know how much of an issue any of that is
>> realistically though. But Andrei may have other reasons why it would be a
>> problem.
>>
>
> You are right, destructor is an issue. The risk of name collision exists as well but I don't think it is realistically that widespread in actual codebase.

Yet another reason why those variable should be declared as such in the `in` clause. Variables declared in the `in` clause using the `out` attribute would have their destruction done after the `out` clause, and all other variables declared in the `in` clause would be destructed after the `in` clause.

On 5/27/13 3:21 AM, Idan Arye wrote:
> Wouldn't it be simpler to define in the `in` clause what to pass to the
> out clause? Something like:
>
> class A {
> void fun()
> in { out oldLen = this.length; }
> out { assert(this.length == oldLen + 1); }
> body { ... }
> }
>
> Or even combine the two:
>
> class A {
> void fun()
> in { out oldLen = this.length; }
> out { assert(this.length == in.oldLen + 1); }
> body { ... }
> }

I think that got too cute.

Andrei

On 5/27/13 3:37 AM, deadalnix wrote:
> On Sunday, 26 May 2013 at 00:43:36 UTC, Andrei Alexandrescu wrote:
>> That was technically difficult to do back then, and fell by the
>> wayside. Today it would break too much code to introduce even if
>> feasible.
>>
>
> Can you expand more on the breakage risk please ?

Easy - name collisions between the in and the out blocks.

Andrei

On 5/27/13 3:42 AM, Jonathan M Davis wrote:
> On Monday, May 27, 2013 09:37:38 deadalnix wrote:
>> On Sunday, 26 May 2013 at 00:43:36 UTC, Andrei Alexandrescu wrote:
>>> That was technically difficult to do back then, and fell by the
>>> wayside. Today it would break too much code to introduce even
>>> if feasible.
>>
>> Can you expand more on the breakage risk please ?
>
> If nothing else, it would mean that the variables inside of the in block would
> not go out of scope when the in block ended, so their destructors would not be
> called and the like, whereas now they would be. The same goes for scope
> statements in the in block. I don't know how much of an issue any of that is
> realistically though. But Andrei may have other reasons why it would be a
> problem.

Oh, destructors too.

Andrei