Having optional parentheses does lead to unresolvable ambiguities. How much of a problem that really is is debatable, but let's assume it should be resolved. To resolve it, a property must be distinguishable from a regular function.

One way is to simply add a "property" attribute keyword:

  property bool empty() { ... }
  property void empty(bool b) { ... }

The problem is that:

1. there are a lot of keywords already
2. keywords are global things

The alternative is to have a unique syntax for properties. Ideally, the syntax should be intuitive and mimic its use. After much fiddling, and based on n.g. suggestions, Andrei and I penciled in:

  bool empty { ... }
  void empty=(bool b) { ... }

The only problem is when a declaration but not definition is desired:

  bool empty;

but oops! That defines a field. So we came up with essentially a hack:

  bool empty{}

i.e. the {} means the getter is declared, but defined elsewhere.

What do you think?

Walter Bright Wrote:
> but oops! That defines a field. So we came up with essentially a hack:
> 
>    bool empty{}

weird syntax

I'd rather use

   bool empty=() { ... }
   void empty=(bool b) { ... }

Walter Bright wrote:
> Having optional parentheses does lead to unresolvable ambiguities. How much of a problem that really is is debatable, but let's assume it should be resolved. To resolve it, a property must be distinguishable from a regular function.
> 
> One way is to simply add a "property" attribute keyword:
> 
>   property bool empty() { ... }
>   property void empty(bool b) { ... }
> 
> The problem is that:
> 
> 1. there are a lot of keywords already
> 2. keywords are global things
> 

If the annotation (attribute) proposal is adopted (see DIP 6) then property can be considered a compile-time annotation (attribute) and no new global keyword is required.

@property @pure @const @nothrow bool empty() { ... }

or

attribute(property,pure,const,nothrow) bool empty() { ... }

> The alternative is to have a unique syntax for properties. Ideally, the syntax should be intuitive and mimic its use. After much fiddling, and based on n.g. suggestions, Andrei and I penciled in:
> 
>   bool empty { ... }
>   void empty=(bool b) { ... }
> 
> The only problem is when a declaration but not definition is desired:
> 
>   bool empty;
> 
> but oops! That defines a field. So we came up with essentially a hack:
> 
>   bool empty{}
> 
> i.e. the {} means the getter is declared, but defined elsewhere.
> 
> What do you think?

Ugly :)

Walter Bright wrote:

>    bool empty { ... }
>    void empty=(bool b) { ... }
> 
> The only problem is when a declaration but not definition is desired:
> 
>    bool empty;
> 
> but oops! That defines a field. So we came up with essentially a hack:
> 
>    bool empty{}
> 
> i.e. the {} means the getter is declared, but defined elsewhere.
> 
> What do you think?

It is quite hack-ish. There are ways to have your cake and eat it too. I wouldn't settle for 'bool empty{}'.

--------------------------------------------------
bool empty {
    void set(auto value) { ... }
    auto get() { ... }
}

empty = false; // empty.set(false)
auto b = empty; // auto b = empty.get()
--------------------------------------------------

for example, requires no hacks and no keywords. And has the added advantage that you can still use the getter and setter methods directly. To call them or get delegates from them.

-- 
Michiel Helvensteijn

Zhenyu Zhou wrote:
> Walter Bright Wrote:
>> but oops! That defines a field. So we came up with essentially a hack:
>>
>>    bool empty{}
> 
> weird syntax

I agree, it's a wart.


> I'd rather use 
> 
>    bool empty=() { ... }
>    void empty=(bool b) { ... }

I suggested that, but Andrei thought it looked unintuitive, and he has a point.

Michiel Helvensteijn Wrote:

> Walter Bright wrote:
> 
> >    bool empty { ... }
> >    void empty=(bool b) { ... }
> > 
> > The only problem is when a declaration but not definition is desired:
> > 
> >    bool empty;
> > 
> > but oops! That defines a field. So we came up with essentially a hack:
> > 
> >    bool empty{}
> > 
> > i.e. the {} means the getter is declared, but defined elsewhere.
> > 
> > What do you think?
> 
> It is quite hack-ish. There are ways to have your cake and eat it too. I wouldn't settle for 'bool empty{}'.
> 
> --------------------------------------------------
> bool empty {
>     void set(auto value) { ... }
>     auto get() { ... }
> }
> 
> empty = false; // empty.set(false)
> auto b = empty; // auto b = empty.get()
> --------------------------------------------------
> 
> for example, requires no hacks and no keywords. And has the added advantage that you can still use the getter and setter methods directly. To call them or get delegates from them.
> 
> -- 
> Michiel Helvensteijn
> 

I think I like this version better than using 'bool var{}' (the var= looks ok IMO, though).

Apparently very similar to the C# approach too (which is shorter, but uses an implicit variable):

     public int humanAge
     {
          get
          {
               return age;
          }
          set
          {
               age = value;
          }
     }

Walter Bright schrieb:
> Zhenyu Zhou wrote:
>> Walter Bright Wrote:
>>> but oops! That defines a field. So we came up with essentially a hack:
>>>
>>>    bool empty{}
>>
>> weird syntax
> 
> I agree, it's a wart.
> 
> 
>> I'd rather use
>>    bool empty=() { ... }
>>    void empty=(bool b) { ... }
> 
> I suggested that, but Andrei thought it looked unintuitive, and he has a point.

Or how about making it a single method?

bool empty=(bool* value){
	if( value ) _empty = *value;
	return _empty;
}

The compiler rewrites the calling code to either pass the address or null.

Walter Bright wrote:

> Having optional parentheses does lead to unresolvable ambiguities. How much of a problem that really is is debatable, but let's assume it should be resolved. To resolve it, a property must be distinguishable from a regular function.
> 
> One way is to simply add a "property" attribute keyword:
> 
>    property bool empty() { ... }
>    property void empty(bool b) { ... }
> 
> The problem is that:
> 
> 1. there are a lot of keywords already
> 2. keywords are global things
> 
> The alternative is to have a unique syntax for properties. Ideally, the syntax should be intuitive and mimic its use. After much fiddling, and based on n.g. suggestions, Andrei and I penciled in:
> 
>    bool empty { ... }
>    void empty=(bool b) { ... }
> 
> The only problem is when a declaration but not definition is desired:
> 
>    bool empty;
> 
> but oops! That defines a field. So we came up with essentially a hack:
> 
>    bool empty{}
> 
> i.e. the {} means the getter is declared, but defined elsewhere.
> 
> What do you think?

It solvs the ambiguities so it would work, might be nicer syntaxes out their but it solvs the main problem.

On 2009-08-02 03:43:43 -0400, Walter Bright <newshound1@digitalmars.com> said:

> Having optional parentheses does lead to unresolvable ambiguities. How much of a problem that really is is debatable, but let's assume it should be resolved. To resolve it, a property must be distinguishable from a regular function.
> 
> One way is to simply add a "property" attribute keyword:
> 
>    property bool empty() { ... }
>    property void empty(bool b) { ... }
> 
> The problem is that:
> 
> 1. there are a lot of keywords already
> 2. keywords are global things

Glad to see you're giving it some tought. :-)


> The alternative is to have a unique syntax for properties. Ideally, the syntax should be intuitive and mimic its use. After much fiddling, and based on n.g. suggestions, Andrei and I penciled in:
> 
>    bool empty { ... }
>    void empty=(bool b) { ... }

I like that. But then (just a question) can you do:

	void empty+=(bool b) { ... }
	void empty++ { ... }
	void ++empty { ... }

?


> The only problem is when a declaration but not definition is desired:
> 
>    bool empty;
> 
> but oops! That defines a field. So we came up with essentially a hack:
> 
>    bool empty{}
> 
> i.e. the {} means the getter is declared, but defined elsewhere.
> 
> What do you think?

I'd prefer this, which can't be misinterpreted as an empty statement:

	bool empty { ... }

It also happens to scale well to any function delcation:

	void foo() { ... }
	void empty=(bool b) { ... }

The way I see it, the other function declaration syntax would still work, except for property getters where you'd need this special one.


-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

Walter Bright wrote:
> Having optional parentheses does lead to unresolvable ambiguities. How much of a problem that really is is debatable, but let's assume it should be resolved. To resolve it, a property must be distinguishable from a regular function.
> 
> One way is to simply add a "property" attribute keyword:
> 
>   property bool empty() { ... }
>   property void empty(bool b) { ... }
> 
> The problem is that:
> 
> 1. there are a lot of keywords already
> 2. keywords are global things

Well, property probably isn't too common a variable name, so it shouldn't impact existing code.

> 
> The alternative is to have a unique syntax for properties. Ideally, the syntax should be intuitive and mimic its use. After much fiddling, and based on n.g. suggestions, Andrei and I penciled in:
> 
>   bool empty { ... }
>   void empty=(bool b) { ... }
> 
> The only problem is when a declaration but not definition is desired:
> 
>   bool empty;
> 
> but oops! That defines a field. So we came up with essentially a hack:
> 
>   bool empty{}
> 
> i.e. the {} means the getter is declared, but defined elsewhere.

Would unimplemented setters look like this:

void empty = (bool b) {}

?

> 
> What do you think?

Looks a bit odd. Perhaps it's just the unfamiliarity of the syntax. Most of us got used to templates, eventually.

My own syntax suggestion requires no new keywords (contextual or otherwise).

interface INameable {

  string name {
    ();
    (value);
  }

}

class Person : INameable {

  private string name_;

  string name {
    () { return name_; }
    (value) { name_ = value; }
  }

}

In the above example, "value" could be anything the class designer wants - to the compiler, empty parentheses () represent the getter, (blah) the setter.