Property discussion wrap-up

[Artur Skawina]

On 01/28/13 00:23, Timon Gehr wrote:
> On 01/27/2013 07:12 PM, Artur Skawina wrote:
>> ...
>> While it's true that "counter-example" is not the best way to describe the issue,
>> it /is/ something that is worth considering. And I say that as somebody who was
>> (and still is) arguing for keeping the last pair of (),
> 
> You can do that in any case.
> 
>> because they carry important info for the person /reading/ the code,
> 
> Often that is not the case.
 
Hmm, let's try an example.
Imagine a project, which defines a set of reasonable policies, such as:

Properties may not:
 - allocate memory
 - grab locks
 - block
 - throw exceptions
 - cause unexpected changes to the program flow (eg no thread ops)
 - etc

Now you only need to make sure that these are followed, either via reviews
and audits, or some checking tool. But once you're reasonably sure that this
is done, you can reason about code, without having to either know or check
absolutely everything - which simply does not scale. So a block like
  
   {
       auto lock = grab.some.lock();
       if (a && b && c.d)
          e = f;
   }

is then safe from certain class of bugs. 

Now welcome the ()-less calls to the party, and you've lost important
information - when auditing you need to make sure that 'a' doesn't
contain a blocking call, does not allocate, does not violate locking
rules etc. Ditto for 'b', 'c', 'c.d', 'e' and 'f'. And everything that
these expressions may call, potentially many levels deep.

Yes, the "proper" way to handle this is using attributes, but that
is not possible now, nor will it be in the near future. OTOH @properties
are already available and in combination with enforcing () on all
other calls can often be used in their place.

Allow parens-less calls, and suddenly the value of having @property
drops significantly, almost to the point that they can be eliminated.
This is why the optional-parens debate is /directly/ related to
@properties.

And this is just one example.

>> but only save one or two keystrokes for the writer. ...
> 
> Again. It is not about saving keystrokes.

OK, so what is the rationale? I'll say upfront that syntax isn't
nearly as important as the ability to reason about code; syntax
is something one can get used to, lost information is gone.

artur