Property discussion wrap-up

[Artur Skawina]

On 01/27/13 17:50, deadalnix wrote:
> On Friday, 25 January 2013 at 18:57:17 UTC, Johannes Pfau wrote:
>> But please keep off-topic stuff, offenses and meta discussion(release
>> process, ...) in the newsgroup.
> 
> Off topic rant.
> 
> I suppressed a counterexample in the section Optional parentheses  - Extra note .
> 
> The note state that some stuff are valid for *function* and the counter example showed ambiguity using opCall. I don't know who did this and I don't care. I however can't stand intellectual dishonesty.
> 
> If your ideas are the best one, such mean move shouldn't be necessary to prove your point.

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 (), because they carry important
info for the person /reading/ the code, but only save one or two keystrokes for the
writer. Removing that example is going too far; this is why a wiki isn't the right
forum for a discussion.

Cases like the removed one [1] was actually why I wanted ()-less calls to be opt-in
(by requiring some kind of @chainable attribute) or the introduction of a separate
operator (so that eg "l->r(A...)" means "r(l, A)") as removing ambiguity is always
good. Not that it would completely fix /this/ particular case; for that you'd need
to require the first parens too, or maybe declare that omitting them is only valid
for ufcs calls.

Still, this case is much less of a problem than having /every/ member access
potentially be a function call. Just defining that opCalls will never be called here
(ie omitting () is only valid for functions) may be acceptable and already an
improvement.

artur

[1]

struct Plain
{
    int a;
}
 
struct Tricky
{
    int a;
    Plain opCall() { return Plain.init }
}
 
void func(int) { }
 
// What happens?
Tricky t;
t.a.func();