@property needed or not needed?

[Rob T]

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