https://issues.dlang.org/show_bug.cgi?id=17474

Eyal <eyal@weka.io> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P3
           Severity|enhancement                 |major

--

https://issues.dlang.org/show_bug.cgi?id=17474

Tomer Filiba (weka) <tomer@weka.io> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |industry
                 CC|                            |tomer@weka.io

--- Comment #1 from Tomer Filiba (weka) <tomer@weka.io> ---
I would like to elaborate a little. The existence/absence of a @property doesn't matter here.

The thing is, the compiler first tries to lower `foo = bar` to `foo(bar)`. If it doesn't work, it will try `foo() = bar` which is what we expect. However, in the case of `foo = null`, the lowering to `foo(null)` does match because you can pass `null` for a string. So, depending on the *value* I'm assigning, it will choose different code paths, even though I'm expecting only the second behavior.

This bug was caught in a UT, but figuring it out required I look at the generated assembly because it was impossible to understand otherwise.

I don't know what's the "right semantics" here. It's basically the interaction of several different features that cause this, but I definitely know it's not what I expect from looking at the code.

--

https://issues.dlang.org/show_bug.cgi?id=17474

ZombineDev <petar.p.kirov@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |petar.p.kirov@gmail.com
           Hardware|x86_64                      |All
                 OS|Linux                       |All

--

https://issues.dlang.org/show_bug.cgi?id=17474

--- Comment #2 from anonymous4 <dfj1esp02@sneakemail.com> ---
If you think it's not a property, you should invoke it with braces.

--

https://issues.dlang.org/show_bug.cgi?id=17474

Stefan Koch <uplink.coder@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |uplink.coder@gmail.com
           Assignee|nobody@puremagic.com        |uplink.coder@gmail.com

--- Comment #3 from Stefan Koch <uplink.coder@gmail.com> ---
I have a pr for this.
Could be a bit more polished though.

Comments welcome.

https://github.com/dlang/dmd/pull/6881

--

https://issues.dlang.org/show_bug.cgi?id=17474

Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla@digitalmars.com

--- Comment #4 from Walter Bright <bugzilla@digitalmars.com> ---
I'm not sure what the "right" semantics are, either, because each of the behaviors can be justified.

But I can suggest avoiding using default function arguments. Default arguments are a good solution for adding parameters without breaking existing code, but are not a good practice otherwise. The behavior observed here, as well as its interaction with overloading, are examples.

The only other thing I can think of is issuing a warning if a function with a default argument is being used as a setter.

--

https://issues.dlang.org/show_bug.cgi?id=17474

--- Comment #5 from Stefan Koch <uplink.coder@gmail.com> ---
(In reply to Walter Bright from comment #4)
> I'm not sure what the "right" semantics are, either, because each of the behaviors can be justified.

I am pretty sure the last thing you want is a function to be invoked as a setter property if it returns an Lvalue.

--

https://issues.dlang.org/show_bug.cgi?id=17474

--- Comment #6 from Tomer Filiba (weka) <tomer@weka.io> ---
(In reply to Walter Bright from comment #4)
> But I can suggest avoiding using default function arguments. Default arguments are a good solution for adding parameters without breaking existing code, but are not a good practice otherwise.

that's exactly what happened -- i added this default parameter to an existing function that did not have parameters, and it broke in a very peculiar way. i ended up using

ref T _fiberLocal(T)(FiberLocalBlock* block) {...}
ref T fiberLocal(T)() {_fiberLocal!T(_currentFiberLocalBlock);}

again, i'm fine with this workaround, but unless our UTs caught that early on, debugging it on a live system would have been impossible.

i agree with stefan that a function returning `ref` shouldn't be allowed in property-setter syntax. either it shouldn't be allowed at all, i.e., `foo = bar` won't compile if foo returns `ref` and takes an argument -- or only allow the lowering to `foo() = bar`

--

https://issues.dlang.org/show_bug.cgi?id=17474

--- Comment #7 from Tomer Filiba (weka) <tomer@weka.io> ---
(In reply to Stefan Koch from comment #5)
> I am pretty sure the last thing you want is a function to be invoked as a setter property if it returns an Lvalue.

+1

--

https://issues.dlang.org/show_bug.cgi?id=17474

--- Comment #8 from Eyal <eyal@weka.io> ---
Requiring @property on a for a=b to invoke a(b) sounds much more reasonable
than the opposite.

I don't see how a=b invoking a(b) when a isn't a @property is justifiable.

--