Property discussion wrap-up

[Timon Gehr]

On 01/28/2013 01:34 AM, Artur Skawina wrote:
> 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.

As long as there is no actual proof, you still need to take all those 
cases into account. If you think otherwise, I do not see why you believe 
that anyone on such a project would leave off the parens when they 
should not be in order to make the above conventions visible at the call 
site.

> So a block like
>
>     {
>         auto lock = grab.some.lock();
>         if (a && b && c.d)
>            e = f;
>     }
>
> is then safe from certain class of bugs.
>

Not yet. You missed the potential memory allocation, lock, blocking 
operation, thrown exception and thread op in e's opAssign.

> 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.
>

Add another policy that states that this must not be necessary. Why 
force your strange conventions on eg. me, who does not even use 
Exceptions, locks, blocking operations or thread ops and does not need 
to tightly control memory allocations beyond some global performance 
considerations, because eg. out of memory does never have too worrisome 
consequences?

And another one about identifier naming. 'a', 'b', 'c', 'c.d', 'e', 'f'?

> Yes, the "proper" way to handle this is using attributes,

Yes.

> but that is not possible now, nor will it be in the near future.

Well, you already bring forward the possibility of having a checking tool.

> OTOH @properties
> are already available and in combination with enforcing () on all
> other calls can often be used in their place.
>

And there are quite a few other ways to achieve the same thing.

> Allow parens-less calls, and suddenly the value of having @property
> drops significantly, almost to the point that they can be eliminated.

Your policies can still be applied, if you like.

> This is why the optional-parens debate is /directly/ related to
> @properties.
>

As far as I am concerned, @properties are mostly sugar most of which is 
not implemented yet.

> 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?

Reading the code. Less noise, compactness of UFCS-chains.
Note that I always add () when leaving them off does not help, eg. for 
simple method calls.

> I'll say upfront that syntax isn't
> nearly as important as the ability to reason about code;

They obviously go hand in hand. But "reasoning" about code that refers 
to definitions one is not aware of any specifications of is just 
rambling anyway.

Also, it is not necessarily good practice to write code that is easier 
to reason about given a handful policies speaking about global program 
state. The problem should be decomposed in a sane way and the concerns 
kept separate instead.

> syntax is something one can get used to, lost information is gone.
>

No information is lost. It's you who defined that any information is 
carried at the call site.