On 2013-01-26 22:48, Artur Skawina wrote:

> Hmm, the current state of them being defined by two separate functions really
> isn't ideal. But introducing new keywords or magic identifiers just for this
> does not seem right.
>
>     class A
>     {
>         private int i;
>         int foo {
>             out { return i; }
>             in(int v) { i = v; }
>         }
>     }
>
> or
>
>     class A
>     {
>         private int i;
>         @property foo {
>             int out { return i; }
>             in(int v) { i = v; }
>         }
>     }

That might conflict with contracts, which also uses "in" and "out".

-- 
/Jacob Carlborg

On 2013-01-27 02:23, Walter Bright wrote:

> Problems if you want to declare the getter but not provide an
> implementation.

Yeah, I noticed that. And declaring a tempalte property.


> It is rather similar to a variable declaration with initializer:
>
>     T foo = expression;

Yeah, you're right.

-- 
/Jacob Carlborg

On 2013-01-27 12:20, Michael wrote:
> int CoolThing { in; out; } - auto property without implementation;
>
> int CoolThing { private in; out; } - private setter; public getter;
>
> int CoolThing
> {
>     in
>     {
>        _privateCoolThing = @value * 42;
>     }
>
>     out
>     {
>        return 42;
>     }
> }
>
> Explicit calling: void in_CoolThing(int); int out_CoolThing(); Proper
> "Property rewrite" can be implemented.
>
> Property CoolThing looks like code contract for _privateCoolThing. So
> it's maybe + or -.
>
> At all, it looks like C# style in D Way.
>
> --no-parenthesis for current behaviour for non-property functions.

Won't this conflict with contracts, which also uses the "in" and "out" keywords?

-- 
/Jacob Carlborg

On 01/27/13 13:02, Jacob Carlborg wrote:
> On 2013-01-26 22:48, Artur Skawina wrote:
> 
>> Hmm, the current state of them being defined by two separate functions really isn't ideal. But introducing new keywords or magic identifiers just for this does not seem right.
>>
>>     class A
>>     {
>>         private int i;
>>         int foo {
>>             out { return i; }
>>             in(int v) { i = v; }
>>         }
>>     }
>>
>> or
>>
>>     class A
>>     {
>>         private int i;
>>         @property foo {
>>             int out { return i; }
>>             in(int v) { i = v; }
>>         }
>>     }
> 
> That might conflict with contracts, which also uses "in" and "out".

It overloads the keywords, but afaict should be unambiguous and is not worse than the other meanings of 'in' (operator, modifier). But I haven't really used contracts w/ D (the basic features need to work right first, before worrying about extras like that); somebody who actually uses them would be in a better position to determine if overloading 'in' and 'out' further would be too confusing.

I mentioned this as a possibility, but am not actually convinced that it's a good idea yet. Things like mixin in getters and setters via separate templates would be impaired - this may be unusual, but doesn't meet the "insane" criteria, so shouldn't be disallowed. Which means several @property blocks would have to be allowed and effectively merged together.

artur

On 01/27/2013 12:35 PM, deadalnix wrote:
> On Sunday, 27 January 2013 at 11:18:01 UTC, sclytrack wrote:
>> On Sunday, 27 January 2013 at 10:54:05 UTC, SomeDude wrote:
>>> On Friday, 25 January 2013 at 04:21:07 UTC, Jonathan M Davis wrote:
>>>>
>>>> I hate optional parentheses with a passion
>>>>
>>>> - Jonathan M Davis
>>>
>>> Same here.
>>
>> In Delphi they are also optional and nobody uses them. However,
>> everybody else doesn't use them.
>>
>
> Delphi has no real functional capabilities.

What about scala?

On Sunday, 27 January 2013 at 12:07:35 UTC, Jacob Carlborg wrote:
> Won't this conflict with contracts, which also uses the "in" and "out" keywords?

As suggestion:
>>Property CoolThing looks like code contract for _privateCoolThing. So it's maybe + or -.

>>At all, it looks like C# style in D Way.

On Sunday, 27 January 2013 at 10:54:05 UTC, SomeDude wrote:
> On Friday, 25 January 2013 at 04:21:07 UTC, Jonathan M Davis wrote:
>>
>> I hate optional parentheses with a passion
>>
>> - Jonathan M Davis
>
> Same here.

If that's the level of abstraction on which you want to discuss about optional parentheses, then I could say that "I love optional parentheses", and since "Love conquers all", my argument would win against your argument.

But, joking aside, I think that all hate against optional parentheses stems from the increase of ambiguity they indisputably cause. However, let's imagine a future where your perfect D IDE paints function calls red, and variables blue. Then, it will be obvious to you which identifiers are variables and which are function calls based on their color. In this situation it will feel silly to have to write those empty parentheses, because they don't make the code any less ambiguous (it's already perfectly unambiguous because of the colors) and, infact, those empty parentheses make the code (a bit) harder to read.

On 2013-01-27 13:52, Artur Skawina wrote:

> It overloads the keywords, but afaict should be unambiguous and is not
> worse than the other meanings of 'in' (operator, modifier). But I haven't
> really used contracts w/ D (the basic features need to work right first,
> before worrying about extras like that); somebody who actually uses them
> would be in a better position to determine if overloading 'in' and 'out'
> further would be too confusing.

I'm not talking about confusing. I'm thinking if it's ambiguous or not and how to attach contracts to a property with this syntax.

-- 
/Jacob Carlborg

On 01/27/2013 02:27 PM, Jacob Carlborg wrote:
> On 2013-01-27 13:52, Artur Skawina wrote:
>
>> It overloads the keywords, but afaict should be unambiguous and is not
>> worse than the other meanings of 'in' (operator, modifier). But I haven't
>> really used contracts w/ D (the basic features need to work right first,
>> before worrying about extras like that); somebody who actually uses them
>> would be in a better position to determine if overloading 'in' and 'out'
>> further would be too confusing.
>
> I'm not talking about confusing. I'm thinking if it's ambiguous or not
> and how to attach contracts to a property with this syntax.
>

class A{
    private int i;
    int foo{
        out out(result){assert(result<=0);}body{return i; }
        in(int v)in{assert(v<=0);}out{assert(foo<=0);}body{ i = v; }
    }
}

On Sunday, 27 January 2013 at 13:24:31 UTC, TommiT wrote:
> But, joking aside, I think that all hate against optional parentheses stems from the increase of ambiguity they indisputably cause. However, let's imagine a future where your perfect D IDE paints function calls red, and variables blue. Then, it will be obvious to you which identifiers are variables and which are function calls based on their color. In this situation it will feel silly to have to write those empty parentheses, because they don't make the code any less ambiguous (it's already perfectly unambiguous because of the colors) and, infact, those empty parentheses make the code (a bit) harder to read.

If we require clever IDE to distinguish visually something as basic as data semantics and callable semantics it is an indicator language design is screwed. Relying on IDE features is what made Java unusable for expressive, robust code. I may use an IDE help when I need to learn architecture level connections in new project, but at scope level semantics for reader should be perfectly clear and unambiguous even if opened in notepad.

2 cents from vim user and optional parens hater here.