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
