On Monday, 21 May 2018 at 14:19:35 UTC, Steven Schveighoffer wrote:
> On 5/21/18 8:15 AM, SrMordred wrote:
>> Right, so this should´n be working I think.
>> 
>>> struct SomeStruct
>>> {
>>>     void foo(int);
>>> }
>>>
>>> SomeStruct s;
>>> s.foo = 10;
>> 
>> I thought that only with @property this will work.
>> 
>
> That was the plan, but it got derailed.
>
> Whoever wrote that original line of code, they need a stern talking-to.
>
> -Steve

While wearing the naughty pointy hat and sitting in a corner :p

On Monday, 21 May 2018 at 18:53:19 UTC, Jonathan M Davis wrote:
>
> writeln = "foo";
>
> is legal, and it's dumb, but it hasn't mattered much in practice. So, causing a bunch of code breakage in order to disallow it is unlikely to go over well. It would also then make getters and setters inconsistent in that setters would require @property and getters wouldn't. How much that matters is debatable, but it does make such a change less palatable.
>
> [...]


Can't assignment to a function be fixed though? Are there any cases where fixing that will cause problems for @property free functions because they all must take more that one parameter i assume.

It's quite a big wart so we don't have to fix all of @property at least, but that should be fixed if fixing it does not crap on UFCS and @property free functions.

On 5/22/18 9:48 AM, aliak wrote:
> On Monday, 21 May 2018 at 18:53:19 UTC, Jonathan M Davis wrote:
>>
>> writeln = "foo";
>>
>> is legal, and it's dumb, but it hasn't mattered much in practice. So, causing a bunch of code breakage in order to disallow it is unlikely to go over well. It would also then make getters and setters inconsistent in that setters would require @property and getters wouldn't. How much that matters is debatable, but it does make such a change less palatable.
>>
>> [...]
> 
> 
> Can't assignment to a function be fixed though? Are there any cases where fixing that will cause problems for @property free functions because they all must take more that one parameter i assume.
> 
> It's quite a big wart so we don't have to fix all of @property at least, but that should be fixed if fixing it does not crap on UFCS and @property free functions.
> 

The derailed plan was to leave alone the ability to call no-arg functions without parentheses, but to REQUIRE @property to call an argument-taking function with the assignment style.

See the DIP here: https://wiki.dlang.org/DIP23

Written by Walter and Andrei. I can't remember why it didn't happen.

-Steve

On Tuesday, May 22, 2018 13:48:16 aliak via Digitalmars-d-learn wrote:
> On Monday, 21 May 2018 at 18:53:19 UTC, Jonathan M Davis wrote:
> > writeln = "foo";
> >
> > is legal, and it's dumb, but it hasn't mattered much in practice. So, causing a bunch of code breakage in order to disallow it is unlikely to go over well. It would also then make getters and setters inconsistent in that setters would require @property and getters wouldn't. How much that matters is debatable, but it does make such a change less palatable.
> >
> > [...]
>
> Can't assignment to a function be fixed though? Are there any cases where fixing that will cause problems for @property free functions because they all must take more that one parameter i assume.
>
> It's quite a big wart so we don't have to fix all of @property at least, but that should be fixed if fixing it does not crap on UFCS and @property free functions.

A free function with a single argument works just fine as a setter property. e.g. you could do something like

void env(Tuple!(string, string)[] str)
{
    // set environment variables
}

env = [tuple("foo", "bar")];

is perfectly legal. I question that there are many cases where such a function would be considered good design, but basically any case where it would make sense to have a function act like a global variable is currently allowed but would be disallowed if you couldn't have a setter property with only one argument.

- Jonathan M Davis

On Tuesday, 22 May 2018 at 13:59:16 UTC, Steven Schveighoffer wrote:
> The derailed plan was to leave alone the ability to call no-arg functions without parentheses, but to REQUIRE @property to call an argument-taking function with the assignment style.
>
> See the DIP here: https://wiki.dlang.org/DIP23
>
> Written by Walter and Andrei. I can't remember why it didn't happen.
>
> -Steve

Aha. Thanks for the link!

It feels like the only difference between a no-arg function that is @property and one that is not is that the former could be invoked with optional parentheses and the latter should be illegal with parentheses.

Whereas an argument taking function marked as @property should probably allow read or write operations depending on whether or not it's invoked with an implicit first argument or not:

@property int f(int) { ... }
1.f; // read op
f = 1; // write op

And to make parentheses illegal as well of course.

On Tuesday, 22 May 2018 at 14:33:20 UTC, Jonathan M Davis wrote:
> A free function with a single argument works just fine as a setter property. e.g. you could do something like
>
> void env(Tuple!(string, string)[] str)
> {
>     // set environment variables
> }
>
> env = [tuple("foo", "bar")];
>
> is perfectly legal. I question that there are many cases where such a function would be considered good design, but basically any case where it would make sense to have a function act like a global variable is currently allowed but would be disallowed if you couldn't have a setter property with only one argument.
>
> - Jonathan M Davis

That can be attributed with @property if the developer intends for it to be used in that way, else should be illegal.

On Thursday, 24 May 2018 at 22:03:38 UTC, aliak wrote:
> It feels like the only difference between a no-arg function that is @property and one that is not is that the former could be invoked with optional parentheses and the latter should be illegal with parentheses.

Edit: err... other way around!