[Issue 17474] non-property being treated as a property
https://issues.dlang.org/show_bug.cgi?id=17474 Iain Buclaw changed: What|Removed |Added Priority|P3 |P2 --
[Issue 17474] non-property being treated as a property
https://issues.dlang.org/show_bug.cgi?id=17474 Stefan Koch changed: What|Removed |Added Assignee|uplink.co...@gmail.com |nob...@puremagic.com --
[Issue 17474] non-property being treated as a property
https://issues.dlang.org/show_bug.cgi?id=17474 --- Comment #11 from Eyal --- (In reply to anonymous4 from comment #10) > (In reply to Eyal from comment #8) > > 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. > > It reduces code littering (and it's not easier to check). UFCS relies on > property syntax too. What code littering does it reduce? @property is not littering, it is informative. UCFS doesn't rely on property syntax, lack of parenthesis relies on property syntax - but not on *setter* syntax, just *getter*. So I repeat: There is no justification for x=y calling x(y) when x is not a @property. --
[Issue 17474] non-property being treated as a property
https://issues.dlang.org/show_bug.cgi?id=17474 --- Comment #10 from anonymous4 --- (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. AFAIK it's deliberate as this way you can implement getter and setter with one function. The right semantics here will be difficult to define due to sheer number of reasons why a(b) may fail to compile and which of them should be skipped and which shouldn't. (In reply to Eyal from comment #8) > 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. It reduces code littering (and it's not easier to check). UFCS relies on property syntax too. --
[Issue 17474] non-property being treated as a property
https://issues.dlang.org/show_bug.cgi?id=17474 --- Comment #9 from Vladimir Panteleev --- (In reply to Eyal from comment #8) > I don't see how a=b invoking a(b) when a isn't a @property is justifiable. Yep, that `writeln = "Hello, world!";` works is an infamous weirdness about D properties. --
[Issue 17474] non-property being treated as a property
https://issues.dlang.org/show_bug.cgi?id=17474 --- Comment #8 from Eyal --- 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. --
[Issue 17474] non-property being treated as a property
https://issues.dlang.org/show_bug.cgi?id=17474
--- Comment #6 from Tomer Filiba (weka) ---
(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`
--
[Issue 17474] non-property being treated as a property
https://issues.dlang.org/show_bug.cgi?id=17474 --- Comment #7 from Tomer Filiba (weka) --- (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 --
[Issue 17474] non-property being treated as a property
https://issues.dlang.org/show_bug.cgi?id=17474 --- Comment #5 from Stefan Koch --- (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. --
[Issue 17474] non-property being treated as a property
https://issues.dlang.org/show_bug.cgi?id=17474 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #4 from Walter Bright --- 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. --
[Issue 17474] non-property being treated as a property
https://issues.dlang.org/show_bug.cgi?id=17474 Stefan Koch changed: What|Removed |Added CC||uplink.co...@gmail.com Assignee|nob...@puremagic.com|uplink.co...@gmail.com --- Comment #3 from Stefan Koch --- I have a pr for this. Could be a bit more polished though. Comments welcome. https://github.com/dlang/dmd/pull/6881 --
[Issue 17474] non-property being treated as a property
https://issues.dlang.org/show_bug.cgi?id=17474 --- Comment #2 from anonymous4 --- If you think it's not a property, you should invoke it with braces. --
[Issue 17474] non-property being treated as a property
https://issues.dlang.org/show_bug.cgi?id=17474 ZombineDev changed: What|Removed |Added CC||petar.p.ki...@gmail.com Hardware|x86_64 |All OS|Linux |All --
[Issue 17474] non-property being treated as a property
https://issues.dlang.org/show_bug.cgi?id=17474 Tomer Filiba (weka) changed: What|Removed |Added Keywords||industry CC||to...@weka.io --- Comment #1 from Tomer Filiba (weka) --- 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. --
[Issue 17474] non-property being treated as a property
https://issues.dlang.org/show_bug.cgi?id=17474 Eyal changed: What|Removed |Added Priority|P1 |P3 Severity|enhancement |major --
