On Tuesday, 20 November 2012 at 13:26:17 UTC, Adam D. Ruppe wrote:
On Tuesday, 20 November 2012 at 12:44:44 UTC, Jacob Carlborg
wrote:
Should this be allowed for functions that isn't marked with
@property:
foo = 3;
Yes. We should *only* be changing the way @property is
implemented. (Namely, actually implementing it!)
Don't want to break existing code. The new changes must be opt
in.
Here's another way to test if the idea is sound, by asking a few
questions:
For some time, we've had the unrestricted ability to drop empty
"()" and perform assignments to any function with appropriate
sig. Has there been a chorus of complaints about having it? Any
flood of problems caused by it? More importantly, how many of us
are now making good use out of it without even a seconds thought?
How many of us would really miss it if taken out?
I still think there's a lot more to the picture, but I cannot yet
pin it down well enough to say what it is.
I'll try and share my thoughts, so that maybe someone more
knowledgeable than me can figure it out.
What is really bugging me, is that I know there's something more
generalized going on here that we may have an opportunity to take
advantage of, before things get cast in "unbreakable" stone, so
to speak.
I've been asking myself some questions, off the wall stuff, not
necessarily possible for D due to practical limitations, but
perhaps possible for E:
1) Why must a variable operate as it does and why must a function
operate as it does? Are the two "things" really all that much
different? I can successfully imagine that a variable is a
function wrapper around a data store.
2) We're allowing only some functions to operate like variables,
and this is because not all functions are allowed to operate in
this way due to their parameter signature. Specifically, if the
function has more than one parameter, it cannot be used as if it
were a variable.
Example:
// We can do this
void Foo( int ){ ... };
int Foo(){ ... };
Foo = 5;
int Y = Foo;
// so why not something like this?
void Foo( int, string, float ){ ... };
( int, string, float )Foo(){ ... };
Foo = { 1, "test", 3.456 };
{ someint, somestring, sonefloat } = Foo;
Why must we be limited to a single return and a single assignment
value?
(I recall this topic was brought up before, and I know we can use
struct to emulate a similar effect)
3) If some functions can operate like variables, then why must no
variable be able to operate like some functions?
This is not allowed in D:
int x, y;
x(1);
y = x();
y(x());
Why must this be so?
4) Which syntax or constructs are easier to understand, and which
are not, given the context they are used in? If we had choice,
will the context prefer one syntax over another in terms of
clarity? If we don't have choice, then the context may enforce
poor clarity in some cases.
5) We really enjoy the power we get from generic templates, yet
the generic abilities of templates may possibly be lessened
considerably because of the incompatibility between variables and
functions, and I would also say classes and structs, although
with UFCS the situation has improved (which may be why we like
having them so much).
6) What advantage do we get by making variables and functions
incompatible with each other (in terms with how they are
manipulated or operated on), and what advantages could we get if
we made them fully compatible (or at least more compatible).
Hopefully some of these questions will provide food for some
thought on the @property matter.
--rt
