Would everyone be able to agree to only use @property functions as properties?  This would still allow omittable parens as a way to make call-chaining and ufcs nicer.

The limitation this imposes is that
  void foo(int a) {...}
  void bar(int a, int b) {...}
cannot be called in this way:
  foo = 2;
  2.bar = 3;

As a consequence, everyone's favorite
  writeln = "lolwut";
does not compile.

What is still allowed:
  int foo() {...}
  void @property bar(int a) {...}
  ...
  int x = foo;
  bar = x;
  auto r = lets.chain!(q).some.stuff;

Although this seems like a distinction that's been discussed, I could never really tell if there was consensus on this.

Admittedly, I stopped following the "@property needed or not needed?" discussion halfway through.

As someone who has taken a stab at doing semantic property rewriting, I think this is a limitation that could potentially help us in the long run.  It simplifies detection of properties: properties are only the things explicitly marked as such, and functions with omitted parens can follow a simpler codepath that the in-depth semantic rewrites can safely ignore.

why in the hell would you want:

    writeln = "lolwut";

to compile in the first place?

On 01/28/2013 08:09 PM, F i L wrote:
> why in the hell would you want:
>
> writeln = "lolwut";
>
> to compile in the first place?
>

Dunno.

But it does right now ;)

On Tuesday, 29 January 2013 at 00:56:41 UTC, Chad Joan wrote:
> snip
>
> The limitation this imposes is that
>   void foo(int a) {...}
>   void bar(int a, int b) {...}
> cannot be called in this way:
>   foo = 2;
>   2.bar = 3;
>
> snip

I have been following the properties discussion a bit and lack
the experience to really comment on much. However, looking at
your posting I couldn't help but ask one question.

You state that not allowing at statement like:

2.bar = 3;

is a 'limitation'. Was 'limitation' really the word you were
looking for?
I find such code rather baffling. Perhaps it has valuable uses
somewhere, which is why I am asking.

It sort of reminds me of Python where you can do something like:

' '.join( list_of_strings )

which is very cute and all, but the following, rather mundane
function call would do a better job of conveying to the reader
what is going on, using the same number of keystrokes:

join( list_of_strings, ' ')

Craig

On 01/28/2013 08:59 PM, Craig Dillabaugh wrote:
> On Tuesday, 29 January 2013 at 00:56:41 UTC, Chad Joan wrote:
>> snip
>>
>> The limitation this imposes is that
>> void foo(int a) {...}
>> void bar(int a, int b) {...}
>> cannot be called in this way:
>> foo = 2;
>> 2.bar = 3;
>>
>> snip
>
> I have been following the properties discussion a bit and lack
> the experience to really comment on much. However, looking at
> your posting I couldn't help but ask one question.
>
> You state that not allowing at statement like:
>
> 2.bar = 3;
>
> is a 'limitation'. Was 'limitation' really the word you were
> looking for?
> I find such code rather baffling. Perhaps it has valuable uses
> somewhere, which is why I am asking.
>
> It sort of reminds me of Python where you can do something like:
>
> ' '.join( list_of_strings )
>
> which is very cute and all, but the following, rather mundane
> function call would do a better job of conveying to the reader
> what is going on, using the same number of keystrokes:
>
> join( list_of_strings, ' ')
>
> Craig

I mean limitation in the mathematical sense.

It's a combination of syntax elements that are valid in current D, but would no longer be valid if the D community were to desire a properties solution that includes this condition.

If no one is harmed by this limitation, then it is still a "limitation", and also a /useful/ limitation.

On Tuesday, 29 January 2013 at 01:09:17 UTC, F i L wrote:
> why in the hell would you want:
>
>     writeln = "lolwut";
>
> to compile in the first place?

If you disallow this. You will have to invent something else than opDispatch.
Something that serves them both. opPropMethodDispatch maybe.

On Tuesday, 29 January 2013 at 02:54:44 UTC, Chad Joan wrote:
> On 01/28/2013 08:59 PM, Craig Dillabaugh wrote:
>> On Tuesday, 29 January 2013 at 00:56:41 UTC, Chad Joan wrote:
>>> snip
>>>
>>> The limitation this imposes is that
>>> void foo(int a) {...}
>>> void bar(int a, int b) {...}
>>> cannot be called in this way:
>>> foo = 2;
>>> 2.bar = 3;
>>>
>>> snip
>>
>> I have been following the properties discussion a bit and lack
>> the experience to really comment on much. However, looking at
>> your posting I couldn't help but ask one question.
>>
>> You state that not allowing at statement like:
>>
>> 2.bar = 3;
>>
>> is a 'limitation'. Was 'limitation' really the word you were
>> looking for?
>> I find such code rather baffling. Perhaps it has valuable uses
>> somewhere, which is why I am asking.
>>
>> It sort of reminds me of Python where you can do something like:
>>
>> ' '.join( list_of_strings )
>>
>> which is very cute and all, but the following, rather mundane
>> function call would do a better job of conveying to the reader
>> what is going on, using the same number of keystrokes:
>>
>> join( list_of_strings, ' ')
>>
>> Craig
>
> I mean limitation in the mathematical sense.
>
> It's a combination of syntax elements that are valid in current D, but would no longer be valid if the D community were to desire a properties solution that includes this condition.
>
> If no one is harmed by this limitation, then it is still a "limitation", and also a /useful/ limitation.

Thanks. That is what I was hoping was the case. I was just
curious if perhaps such obscure looking code enabled certain
idioms that somehow made the language more powerful.

On Tuesday, 29 January 2013 at 00:56:41 UTC, Chad Joan wrote:
> Would everyone be able to agree to only use @property functions as properties?

I think @property-ies should not be taken for functions... at least conceptually.

I think the root reason why such confusion is the bad choice that D made in the beginning, to define properties with the same syntax as functions, while properties should be rather an extensions of the variable concept, not of the functions concept.

For the programmer using a property, he should not even be aware that it is a function (or a property). He should think that it is a variable and that's all.

The C# syntax is closer to this approach. More, it is strongly linking the code (of both the getter and the setter) with the considered property. In D, this link is quite loose.

Let me turn the table: why not thinking about the property as a variable that, optionally (start another UFCS/opt-parens discussion here...) accept the syntax:

v(2);

(besides the obvious v=2). This happens in C++ where you can define either int x= 3; either int x(3).

More confusing?

On Tuesday, 29 January 2013 at 01:24:45 UTC, Chad Joan wrote:
> On 01/28/2013 08:09 PM, F i L wrote:
>> why in the hell would you want:
>>
>> writeln = "lolwut";
>
> But it does right now ;)

Joking here, but what about renaming writeln into cout and overloading the <<?

On Tuesday, 29 January 2013 at 08:05:25 UTC, eles wrote:
> On Tuesday, 29 January 2013 at 01:24:45 UTC, Chad Joan wrote:
>> On 01/28/2013 08:09 PM, F i L wrote:
>>> why in the hell would you want:
>>>
>>> writeln = "lolwut";
>>
>> But it does right now ;)
>
> Joking here, but what about renaming writeln into cout and overloading the <<?

Great idea :)

import std.stdio;
struct COut {
    COut opBinary(string op, T)(T other) if(op == "<<") {
            write(other);
            return this;
    }
}

@property COut cout() {
    return COut();
}

void main() {
    cout << "cout" << " " << "rocks" << "\n";
}