Andrei Alexandrescu wrote:
> I think we all agree that there are some annoyances related to the whole property business, among which the main one is:
> 
> writeln = 4;
> 
> That is quite indefensible :o|. I consider the others rather minor, but that's just a personal opinion.
> 
> How about this. Maybe if we attacked this annoyance in particular, that would be a large bang for the buck without a landslide change in the compiler. We only need some way to inform the compiler, "yes, it's ok to call a.b(c) as a.b = c". Ideas?
> 

Using an equals sign to say that assignment syntax is allowed seems natural:

void prop(=int x) { }  // assignment syntax ok
void prop(= int x) { }  // same thing

Other cases:
void prop(=int x=0) { }  // can called as 'prop;' or 'int z = prop;'
void prop(=int x, int y) { }  // probably syntax error
void prop(=int x, int y=0) { }  // unusual but ok?


Functions with no arguments can still be called without parens.

torhu wrote:
> Other cases:
> void prop(=int x=0) { }  // can called as 'prop;' or 'int z = prop;'

Oops, I meant "can be called as 'prop;' or 'prop = 7;'

torhu wrote:
> Andrei Alexandrescu wrote:
>> I think we all agree that there are some annoyances related to the whole property business, among which the main one is:
>>
>> writeln = 4;
>>
>> That is quite indefensible :o|. I consider the others rather minor, but that's just a personal opinion.
>>
>> How about this. Maybe if we attacked this annoyance in particular, that would be a large bang for the buck without a landslide change in the compiler. We only need some way to inform the compiler, "yes, it's ok to call a.b(c) as a.b = c". Ideas?
>>
> 
> Using an equals sign to say that assignment syntax is allowed seems natural:
> 
> void prop(=int x) { }  // assignment syntax ok
> void prop(= int x) { }  // same thing
> 
> Other cases:
> void prop(=int x=0) { }  // can called as 'prop;' or 'int z = prop;'
> void prop(=int x, int y) { }  // probably syntax error
> void prop(=int x, int y=0) { }  // unusual but ok?
> 
> 
> Functions with no arguments can still be called without parens.

My concern is that this could break existing code.  If the presence of an equals sign allows the use of the property syntax, then suddenly code needs to be updated that is supposed to be able to be used like a property.  Perhaps something to explicitly disallow the use of the property syntax?

Chris R. Miller wrote:
> torhu wrote:
>> Using an equals sign to say that assignment syntax is allowed seems natural:
>> 
>> void prop(=int x) { }  // assignment syntax ok
>> void prop(= int x) { }  // same thing
>> 
>> Other cases:
>> void prop(=int x=0) { }  // can called as 'prop;' or 'int z = prop;'
>> void prop(=int x, int y) { }  // probably syntax error
>> void prop(=int x, int y=0) { }  // unusual but ok?
>> 
>> 
>> Functions with no arguments can still be called without parens.
> 
> My concern is that this could break existing code.  If the presence of an equals sign allows the use of the property syntax, then suddenly code needs to be updated that is supposed to be able to be used like a property.  Perhaps something to explicitly disallow the use of the property syntax?

Well, isn't this just for D 2.0?  The implicit property setters could be just deprecated, like volatile recently was, so compiling with -d will make them work again.

On Sun, 28 Sep 2008 05:45:58 +0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> Sergey Gromov wrote:
>> Sat, 27 Sep 2008 15:19:01 -0500,
>> Andrei Alexandrescu wrote:
>>> My point is that I agree with all concerns you are raising but I am not
>>> sure they warrant adding a language feature.
>>  I hoped for some reason that these features could simplify the compiler.  Now when I think about it I conclude that I was probably wrong.  Explicit properties is definitely a feature, even though it seems easy to implement. Injectons could help if Walter were forced into supporting different scoping rules for unified call syntax, but if a.f(b) stays strictly a sugar for f(a,b) this feature helps nothing from a compiler standpoint.
>>  So I'll probably agree that these features don't add much to the language, as D doesn't add much to C except safety, productivity, maintainability and claritiy.  The clarity/maintainability vs genericity is a tradeoff which is completely in Walter's hands.
>
> Very wise words.
>
> I think we all agree that there are some annoyances related to the whole property business, among which the main one is:
>
> writeln = 4;
>
> That is quite indefensible :o|. I consider the others rather minor, but that's just a personal opinion.
>
> How about this. Maybe if we attacked this annoyance in particular, that would be a large bang for the buck without a landslide change in the compiler. We only need some way to inform the compiler, "yes, it's ok to call a.b(c) as a.b = c". Ideas?
>
>
> Andrei

I think property syntax should be disallowed by default. Most of the functions aren't expected to be used as a property, anyway.
It would break the code, yes, but it is very easy to fix.

Solution of my preference:

class Foo
{
    // allow property syntax:
    property void bar(int baz); // allows "foo.bar = 42;"

    // allow omitting parens
    property int bar();         // allows writing "int x = foo.bar;"
}

Think long term, don't be afraid to break existing code and introduce new features if they improve the language signaficantly. Wrong decision made today may make huge negative impact over time.

Jason House wrote:
> Andrei Alexandrescu wrote:
>  
>> I think we all agree that there are some annoyances related to the whole
>> property business, among which the main one is:
>>
>> writeln = 4;
>>
>> That is quite indefensible :o|. I consider the others rather minor, but
>> that's just a personal opinion.
>>
>> How about this. Maybe if we attacked this annoyance in particular, that
>> would be a large bang for the buck without a landslide change in the
>> compiler. We only need some way to inform the compiler, "yes, it's ok to
>> call a.b(c) as a.b = c". Ideas?
> 
> That seems like a bad idea if it allows a forgetful/lazy/overworked library
> writer to cause users to be unable to use property syntax in natural cases. I'd say explicit forbidding of property syntax is a better idea.
> 
> Based on some people's view of properties, allowing property get syntax for
> pure functions would make a lot of sense.  Others would hate that.  I'm not
> sure if restricting users would be all that popular.  It may be better
> placed in some kind of lint tool.

But I'm talking about property set syntax, not get.

Andrei

Denis Koroskin wrote:
> On Sun, 28 Sep 2008 05:45:58 +0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> 
>> Sergey Gromov wrote:
>>> Sat, 27 Sep 2008 15:19:01 -0500,
>>> Andrei Alexandrescu wrote:
>>>> My point is that I agree with all concerns you are raising but I am not
>>>> sure they warrant adding a language feature.
>>>  I hoped for some reason that these features could simplify the compiler.  Now when I think about it I conclude that I was probably wrong.  Explicit properties is definitely a feature, even though it seems easy to implement. Injectons could help if Walter were forced into supporting different scoping rules for unified call syntax, but if a.f(b) stays strictly a sugar for f(a,b) this feature helps nothing from a compiler standpoint.
>>>  So I'll probably agree that these features don't add much to the language, as D doesn't add much to C except safety, productivity, maintainability and claritiy.  The clarity/maintainability vs genericity is a tradeoff which is completely in Walter's hands.
>>
>> Very wise words.
>>
>> I think we all agree that there are some annoyances related to the whole property business, among which the main one is:
>>
>> writeln = 4;
>>
>> That is quite indefensible :o|. I consider the others rather minor, but that's just a personal opinion.
>>
>> How about this. Maybe if we attacked this annoyance in particular, that would be a large bang for the buck without a landslide change in the compiler. We only need some way to inform the compiler, "yes, it's ok to call a.b(c) as a.b = c". Ideas?
>>
>>
>> Andrei
> 
> I think property syntax should be disallowed by default. Most of the functions aren't expected to be used as a property, anyway.

By whom aren't they expected?

> It would break the code, yes, but it is very easy to fix.
> 
> Solution of my preference:
> 
> class Foo
> {
>     // allow property syntax:
>     property void bar(int baz); // allows "foo.bar = 42;"
> 
>     // allow omitting parens
>     property int bar();         // allows writing "int x = foo.bar;"
> }
> 
> Think long term, don't be afraid to break existing code and introduce new features if they improve the language signaficantly. Wrong decision made today may make huge negative impact over time.

Without solid argument, all this is just talk. What is the negative impact over time?


Andrei

Andrei Alexandrescu wrote:
> How about this. Maybe if we attacked this annoyance in particular, that would be a large bang for the buck without a landslide change in the compiler. We only need some way to inform the compiler, "yes, it's ok to call a.b(c) as a.b = c". Ideas?

I actually did have something in mind when I wrote this, just didn't want to bias anyone.

My thinking is that the syntax "a.b = c" in lieu of a.b(c) for a function a.b(T x) should be allowed if and only if there also exists a function a.b() that returns a value of type T.

Example:

struct S1
{
    void prop(int x);
}

S1 s1;
s1 = x; // error, prop is not a property

struct S2
{
    void prop(int x);
    int prop();
}

S2 s2;
s2.prop = 42; // fine, prop is a property because it also has a getter

This solution does not require any syntactic addition. Its drawback is that it makes it hard to define write-only properties. Are they important?


Andrei

torhu wrote:
> Chris R. Miller wrote:
>> torhu wrote:
>>> Using an equals sign to say that assignment syntax is allowed seems natural:
>>>
>>> void prop(=int x) { }  // assignment syntax ok
>>> void prop(= int x) { }  // same thing
>>>
>>> Other cases:
>>> void prop(=int x=0) { }  // can called as 'prop;' or 'int z = prop;'
>>> void prop(=int x, int y) { }  // probably syntax error
>>> void prop(=int x, int y=0) { }  // unusual but ok?
>>>
>>>
>>> Functions with no arguments can still be called without parens.
>>
>> My concern is that this could break existing code.  If the presence of an equals sign allows the use of the property syntax, then suddenly code needs to be updated that is supposed to be able to be used like a property.  Perhaps something to explicitly disallow the use of the property syntax?
> 
> Well, isn't this just for D 2.0?  The implicit property setters could be just deprecated, like volatile recently was, so compiling with -d will make them work again.

D 2.0 isn't so different that every line of code will have to be rewritten for it though.  Why force people to have to rewrite more code for D2.0 if we aren't sure we have to?

Also, are we considering these properties?

void doFoo() { }

int main() {
     doFoo; // same as doFoo();
}

Andrei Alexandrescu wrote:
> Denis Koroskin wrote:
>> On Sun, 28 Sep 2008 05:45:58 +0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>>
>>> Sergey Gromov wrote:
>>>> Sat, 27 Sep 2008 15:19:01 -0500,
>>>> Andrei Alexandrescu wrote:
>>>>> My point is that I agree with all concerns you are raising but I am not
>>>>> sure they warrant adding a language feature.
>>>>  I hoped for some reason that these features could simplify the compiler.  Now when I think about it I conclude that I was probably wrong.  Explicit properties is definitely a feature, even though it seems easy to implement. Injectons could help if Walter were forced into supporting different scoping rules for unified call syntax, but if a.f(b) stays strictly a sugar for f(a,b) this feature helps nothing from a compiler standpoint.
>>>>  So I'll probably agree that these features don't add much to the language, as D doesn't add much to C except safety, productivity, maintainability and claritiy.  The clarity/maintainability vs genericity is a tradeoff which is completely in Walter's hands.
>>>
>>> Very wise words.
>>>
>>> I think we all agree that there are some annoyances related to the whole property business, among which the main one is:
>>>
>>> writeln = 4;
>>>
>>> That is quite indefensible :o|. I consider the others rather minor, but that's just a personal opinion.
>>>
>>> How about this. Maybe if we attacked this annoyance in particular, that would be a large bang for the buck without a landslide change in the compiler. We only need some way to inform the compiler, "yes, it's ok to call a.b(c) as a.b = c". Ideas?
>>>
>>>
>>> Andrei
>>
>> I think property syntax should be disallowed by default. Most of the functions aren't expected to be used as a property, anyway.
> 
> By whom aren't they expected?
> 
>> It would break the code, yes, but it is very easy to fix.
>>
>> Solution of my preference:
>>
>> class Foo
>> {
>>     // allow property syntax:
>>     property void bar(int baz); // allows "foo.bar = 42;"
>>
>>     // allow omitting parens
>>     property int bar();         // allows writing "int x = foo.bar;"
>> }
>>
>> Think long term, don't be afraid to break existing code and introduce new features if they improve the language signaficantly. Wrong decision made today may make huge negative impact over time.
> 
> Without solid argument, all this is just talk. What is the negative impact over time?

Improper use of properties make code that looks ambiguous.  Is that a public member or a method?  It reduces codebase coherency, which is normally not a huge problem except when new programmers are reading through the code to see how it works.  If someone mistook that method call via property as a member, then they might use it as such in code they write.  Because it's actually a method, it has the potential to rope in serious amounts of processor work.

It's the same reason you don't want to overload simple operators in C++ with potentially large algorithms, since it creates an illusion that the operator is really a simple operation when in fact it could be quite tedious.  This is - of course - a matter of practice with C++, and isn't a language requirement, but it does illustrate that it's something to be conscious of.  Similarly, you wouldn't want to load up a D invariant with a lot of hard processor work, since that would incur a lot of overhead following each public function call.  There's nothing explicitly wrong about doing it, it's just bad practice (according to some).

I hope that was coherent.  I believe I read about it in /Code Complete/, if you want a source.