On Wednesday, 4 September 2013 at 15:18:10 UTC, Ary Borenszweig wrote:
> So the problem is not that implicit mixin is unsafe. The problem is that there's no way to declare a new variable that won't conflict with existing variables in the current scope?

This is the same problem. The key property of mixin is that it is unhygienic and invades the caller scope. It is the only entity in D that is allowed to do it. Allowing implicit unhygienic inclusions is guaranteed to result in accidental symbol clash and/or unexpected modification sooner or later.

On Wed, Sep 4, 2013 at 2:23 AM, Dicebot <public@dicebot.lv> wrote:

> On Wednesday, 4 September 2013 at 02:26:27 UTC, Timothee Cour wrote:
>
>> that's the whole point, it allows to transparently replace a field access by a property function call without breaking client code. How else would you do that?
>>
>
> You can't replace field access with function call transparently if it has side effects. In the end breakage may be even worse. For me only replacing @property fields with @property methods makes sense (with former prohibited to be taken address of and latter forced to be weakly pure).'
>

IIRC, &foo.x with x a property should take address of return value of x(), which will either fail to compile or do the right thing if it returns a lvalue. So there's no undefined behavior as far as taking address of is concerned when replacing field by property.

As for side effects, this is the reason one would go from field access to property, eg populating some data upon 1st access to a field x. Sure it can be misused, but I haven't seen a case in practice where it is misused.

frankly, UFCS mixin would make the use case in the OT bearable.

fun().mixin.writeln is ok
mixin(fun()).writeln is ugly (esp in more complex cases).

so, is there anything against it despite requiring one to implement it?


On Wed, Sep 4, 2013 at 8:29 AM, Dicebot <public@dicebot.lv> wrote:

> On Wednesday, 4 September 2013 at 15:18:10 UTC, Ary Borenszweig wrote:
>
>> So the problem is not that implicit mixin is unsafe. The problem is that there's no way to declare a new variable that won't conflict with existing variables in the current scope?
>>
>
> This is the same problem. The key property of mixin is that it is unhygienic and invades the caller scope. It is the only entity in D that is allowed to do it. Allowing implicit unhygienic inclusions is guaranteed to result in accidental symbol clash and/or unexpected modification sooner or later.
>

On Wednesday, 4 September 2013 at 17:07:33 UTC, Timothee Cour wrote:
> IIRC, &foo.x with x a property should take address of return value of x(),
> which will either fail to compile or do the right thing if it returns a
> lvalue.

It is not possible because getters are not guaranteed to return lvalues. There is a quite elegant (in my opinion) proposal hanging around to allow annotating plain fields with @property so that compiler will prohibit doing any operation on them that may later break because of transition to actual properties, such as taking address.

> As for side effects, this is the reason one would go from field access to
> property, eg populating some data upon 1st access to a field x. Sure it can
> be misused, but I haven't seen a case in practice where it is misused.

I haven't seen a case in practice when using normal method instead of a property was really harmful. Also modifying own members is legal for weakly pure method as far as I remember (it can modify arguments, including hidden `this`), so your case will actually work within my restrictions.

On Wednesday, 4 September 2013 at 17:10:32 UTC, Timothee Cour wrote:
> frankly, UFCS mixin would make the use case in the OT bearable.
>
> fun().mixin.writeln is ok
> mixin(fun()).writeln is ugly (esp in more complex cases).
>
> so, is there anything against it despite requiring one to implement it?

I guess there is nothing terrible but also nothing extremely useful :) For me second snippet is not any uglier.

On Thursday, 5 September 2013 at 10:36:40 UTC, Dicebot wrote:
> On Wednesday, 4 September 2013 at 17:10:32 UTC, Timothee Cour wrote:
>> frankly, UFCS mixin would make the use case in the OT bearable.
>>
>> fun().mixin.writeln is ok
>> mixin(fun()).writeln is ugly (esp in more complex cases).
>>
>> so, is there anything against it despite requiring one to implement it?
>
> I guess there is nothing terrible but also nothing extremely useful :) For me second snippet is not any uglier.

Stuff like data validation, or lazy initialization, anything really data oriented usually benefit from that.

Also, the dichotomy function call/field access is really not that clear at the end. Accessing some data may require a function call, go through a signal handler, or involve complicated operation by the CPU (potentially 2 round trip to memory).

On the other hand, optimizer will remove many function calls making them effectively field access. Even if it isn't inlined, a simple function call could end up being faster than 2 round trip to memory (the stack is hot).

On Thursday, 5 September 2013 at 10:51:19 UTC, deadalnix wrote:
> Stuff like data validation, or lazy initialization, anything really data oriented usually benefit from that.
>
> Also, the dichotomy function call/field access is really not that clear at the end. Accessing some data may require a function call, go through a signal handler, or involve complicated operation by the CPU (potentially 2 round trip to memory).
>
> On the other hand, optimizer will remove many function calls making them effectively field access. Even if it isn't inlined, a simple function call could end up being faster than 2 round trip to memory (the stack is hot).

I guess it was an answer to earlier property comment. Key concern here is not actually speed but ease to understand the program - it is pretty much the same deal as pure vs non-pure. Non-volatile non-shared field access is extremely unlikely to cause any side-effects in global program state and same is generally expected from something that looks like plain field access.