On Friday, 1 February 2019 at 23:24:44 UTC, Olivier FAURE wrote:
> On Friday, 1 February 2019 at 09:10:15 UTC, aliak wrote:
>> Shouldn't doubleMyValue(pt.x) be a compiler error if pt.x is a getter? For it not to be a compile error pt.x should also have a setter, in which case the code needs to be lowered to something else:
>
> The thing is, D doesn't really differentiate between a getter and any other method.
>
> So with DIP-1016, when given
>
>     doubleMyValue(pt.x);
>
> The compiler would assume the programmer means
> - Call pt.x()
> - Store the result in a temporary
> - Pass that temporary as a ref parameter to doubleMyValue
>
> At no point is the compiler aware that the user intends for x to be interpreted as a getter.

Languages like c# solve this problem by disallowing passing property to ref parameter arguments.

On 2/1/19 8:15 PM, 12345swordy wrote:
> On Friday, 1 February 2019 at 23:24:44 UTC, Olivier FAURE wrote:
>> On Friday, 1 February 2019 at 09:10:15 UTC, aliak wrote:
>>> Shouldn't doubleMyValue(pt.x) be a compiler error if pt.x is a getter? For it not to be a compile error pt.x should also have a setter, in which case the code needs to be lowered to something else:
>>
>> The thing is, D doesn't really differentiate between a getter and any other method.
>>
>> So with DIP-1016, when given
>>
>>     doubleMyValue(pt.x);
>>
>> The compiler would assume the programmer means
>> - Call pt.x()
>> - Store the result in a temporary
>> - Pass that temporary as a ref parameter to doubleMyValue
>>
>> At no point is the compiler aware that the user intends for x to be interpreted as a getter.
> 
> Languages like c# solve this problem by disallowing passing property to ref parameter arguments.

Such would be a good conservative approach for us too. We can relax it later if we come with a good idea.

On Thursday, 24 January 2019 at 07:18:58 UTC, Mike Parker wrote:

> Walter and Andrei have declined to accept DIP 1016, "ref T accepts r-values", on the grounds that it has two fundamental flaws that would open holes in the language.


> fun(10)
> ==>
> {
>   T __temp0 = void;
>   fun(__temp0 := 10);
> }

> the rewrite is from an expression to a statement, rendering it invalid.

> if the first constructor throws an exception, all remaining values will be destroyed in the void state as they never have the chance to become initialized.

> They say that with the current semantics, this function only operates on long values as it should. With the proposed semantics, the call will accept all shared integral types.

I think this solves all of the above:

fun(10);
==>
(int __temp0){ (return)? fun( __temp0 ); }(10);

-The expression/statement issue is solved by the closure
-The initialization issue created by the ":=" approach is not present here
-For this rewrite, 'T' is the type of the rvalue argument, not the type of the function parameter. This prevents undesired implicit conversions.

On Monday, 4 February 2019 at 17:09:25 UTC, bitwise wrote:

> I think this solves all of the above:
>
> fun(10);
> ==>
> (int __temp0){ (return)? fun( __temp0 ); }(10);
>
> -The expression/statement issue is solved by the closure
> -The initialization issue created by the ":=" approach is not present here
> -For this rewrite, 'T' is the type of the rvalue argument, not the type of the function parameter. This prevents undesired implicit conversions.

I don't understand this.
What does "(return)?" mean? Is this valid D syntax? What do I miss?

On Monday, 4 February 2019 at 18:32:56 UTC, Dominikus Dittes Scherkl wrote:
> I don't understand this.
> What does "(return)?" mean? Is this valid D syntax? What do I miss?

I meant for that to be interpreted like a Regular expression, denoting conditional presence of the return statement. I'm not sure what the proper notation would be to express such a thing.

On Monday, 4 February 2019 at 18:35:37 UTC, bitwise wrote:
> On Monday, 4 February 2019 at 18:32:56 UTC, Dominikus Dittes Scherkl wrote:
>> I don't understand this.
>> What does "(return)?" mean? Is this valid D syntax? What do I miss?
>
> I meant for that to be interpreted like a Regular expression, denoting conditional presence of the return statement. I'm not sure what the proper notation would be to express such a thing.

It's actually fine to leave the `return` there unconditionally--you're allowed to return an expression of type `void` from a function.

Example: https://run.dlang.io/is/tnSGN4

On Monday, 4 February 2019 at 20:08:39 UTC, Paul Backus wrote:
> On Monday, 4 February 2019 at 18:35:37 UTC, bitwise wrote:
>> On Monday, 4 February 2019 at 18:32:56 UTC, Dominikus Dittes Scherkl wrote:
>>> I don't understand this.
>>> What does "(return)?" mean? Is this valid D syntax? What do I miss?
>>
>> I meant for that to be interpreted like a Regular expression, denoting conditional presence of the return statement. I'm not sure what the proper notation would be to express such a thing.
>
> It's actually fine to leave the `return` there unconditionally--you're allowed to return an expression of type `void` from a function.
>
> Example: https://run.dlang.io/is/tnSGN4

Even better ;)

No one else seems particularly excited about the rewrite though - what am I missing?

I suppose a lambda cost significantly more, but I don't think the lambda should make it through the optimizer for this case though.

On Friday, 8 February 2019 at 16:00:58 UTC, bitwise wrote:
> On Monday, 4 February 2019 at 20:08:39 UTC, Paul Backus wrote:
>> On Monday, 4 February 2019 at 18:35:37 UTC, bitwise wrote:
>>> [...]
>>
>> It's actually fine to leave the `return` there unconditionally--you're allowed to return an expression of type `void` from a function.
>>
>> Example: https://run.dlang.io/is/tnSGN4
>
> Even better ;)
>
> No one else seems particularly excited about the rewrite though - what am I missing?
>
> I suppose a lambda cost significantly more, but I don't think the lambda should make it through the optimizer for this case though.

Immediately called lamdas are always inlined.

On Friday, 8 February 2019 at 23:02:34 UTC, Nicholas Wilson wrote:
> Immediately called lamdas are always inlined.

```
extern(C) void main() {
    int a = (() => 1)();
}
```

dmd -inline -O -release -betterC

asm:
```
main:
		push	RBP
		mov	RBP,RSP
		call	qword ptr pure nothrow @nogc @safe int onlineapp.main().__lambda1()@GOTPCREL[RIP]
		xor	EAX,EAX
		pop	RBP
		ret
```

https://run.dlang.io/is/lZW9B6

Still a lambda call :/

On Fri, Feb 08, 2019 at 11:34:47PM +0000, Dennis via Digitalmars-d-announce wrote:
> On Friday, 8 February 2019 at 23:02:34 UTC, Nicholas Wilson wrote:
> > Immediately called lamdas are always inlined.
> 
> ```
> extern(C) void main() {
>     int a = (() => 1)();
> }
> ```
> 
> dmd -inline -O -release -betterC
> 
> asm:
> ```
> main:
> 		push	RBP
> 		mov	RBP,RSP
> 		call	qword ptr pure nothrow @nogc @safe int
> onlineapp.main().__lambda1()@GOTPCREL[RIP]
> 		xor	EAX,EAX
> 		pop	RBP
> 		ret
> ```
> 
> https://run.dlang.io/is/lZW9B6
> 
> Still a lambda call :/

Does LDC/GDC inline it?

I no longer trust dmd for codegen quality. :-/


T

-- 
Customer support: the art of getting your clients to pay for your own incompetence.