@property needed or not needed?

[Rob T]

On Monday, 19 November 2012 at 21:44:35 UTC, Jonathan M Davis 
wrote:
> Excep that i don't think that it's really a question of style. 
> It's treating a
> function as if it were a variable, when it's not only not a 
> variable, but it's
> not even acting like one. It's implying that the code has one 
> set of semantics
> when it has another. Dropping parens when specifically creating 
> a function
> which is intended to emulate a variable makes sense. But 
> dropping parens just
> because you feel like it then makes a function look like a 
> variable when it's
> not and not intended to even act like one. That violates the 
> very difference
> between function and variable on even a conceptual level. It 
> would be one
> thing to make a particular character or sequence of characters 
> optional when
> doing so doesn't make it look like it's something else entirely
>  (e.g.
> optional braces don't make anything look like anything else - 
> they just drop
> some characters, and they don't introduce any ambiguities in 
> the process). But
> it's quite another to make those characters optional when they 
> make one
> language construct look like another.
>
> - Jonathan M Davis

I see what you are saying.

Consider this:

@property allows a function to behave as if it were a variable, 
so in that case we're effectively creating an alternate set of 
language constructs for at least some functions. The enforcement 
through @property however constrains it to only behave as if it 
were a variable and not a function, there's no ambiguity in this 
case, and it's clearly intentional, not a mistake.

Without @property, but allowing the programmer to decide if, 
when, and where, a function may emulate a variable, and when it 
will not, may confuse some people and may also confuse the 
compiler in some cases, but it does offer the programmer 
additional flexibility that may prove to be useful, although it 
may also prove to be a costly mistake, and if so it may be a 
matter of how good the programmer is.

All I know at this point is that because @property was not fully 
implemented as originally intended, I was able to experience the 
flexibility, and personally I found it to be OK for whatever 
reason, esp wrt UFCS.

I would still be happy to have @property perform constraints to 
enforce a function to emulate a variable or to resolve 
ambiguities, and certainly for any function no matter where it 
may be declared. I can definitely see the value in that and I 
can't see any reason for not supporting it.

Side Note: In some cases you may want a setter but no getter for 
write only variable emulation, or a setter but no getter for read 
only emulation.

What is not so clear, is if optional () should be allowed or not, 
but I do understand the argument that it makes the code look 
better in some cases which in that case is a question of style 
rather than anything to do with @property.

Also do not forget that we can not only drop the (), but also 
perform assignments to functions that take in one variable, but 
I'm not sure if the return must be void for that to work. It 
seems strange to allow arbitrarily dual function/variable 
constructs for functions, but being strange does not necessarily 
mean it is wrong.

I do wonder however, if there's something much more fundamental 
or generalized going on with this that can settle the question in 
clear terms? I fully understand the variable emulation argument, 
and it's seems to be sound, however imagine reversing the 
argument and suggesting that all (or some) variables should be 
enforced to emulate function calls with @function.

We've seen this being done in C++, where I can initialize a 
variable in multiple emulated ways:

// class constructor emulation
int x(42);

// function emulation
int y;
x = y(42);

// regular variable form
int x = 42;

I don't have an answer, but there may be more to the picture than 
we think.

--rt