@property - take it behind the woodshed and shoot it?

[H. S. Teoh]

On Fri, Jan 25, 2013 at 08:46:51PM +0100, mist wrote:
> On Friday, 25 January 2013 at 19:30:26 UTC, Jonathan M Davis wrote:
> >...
> 
> I am not going to argue anything, I am just asking _how_ they are
> supposed to work, what are exact semantic. I have added various
> syntax cases to wiki:
> http://wiki.dlang.org/Property_Discussion_Wrap-up#.40property_on_free_functions
> 
> What I am going to argue is if all of those example are supposed to
> work. We can't define property semantics to be "just like data" when
> property symbol can't be just interchanged with data symbol.
> 
> From the syntax point of view no issues there.

>From my stance that @property should make the function behave like a
variable, all of the examples in the above link can be resolved thus:


>	struct Type
>	{
>	    @property void native(int);
>	}

This should behave as though you wrote this:

	struct Type
	{
	    // const because there is no setter
	    const int native;
	}


>	@property void external1(int);       // valid? (no assignment context)

Valid, this is equivalent to defining a module-level variable:

	int external1;


>	@property void external2(Type, int); // valid? (extra parameter comparing to typical setter)

Valid, because UFCS lets you use it as though it were a member variable
of Type.


>	void main()
>	{
>	    Type t;
>	    t.native = 42;    // typical
>	    external1 = 42;   // allowed or not?

Allowed, because external1 behaves like a module-level variable.


>	    42.external1;     // allowed or not?

Not allowed, because the following isn't allowed either:

	int x;
	void main() {
		1.x;  // Error: nonsensical syntax
	}

IOW, @property functions must be treated as variables externally, NOT as
normal functions.


>	    t.external2 = 42; // allowed or not?
>	}

Allowed, because external2, via UFCS, behaves as though it were a member
variable of Type.

All of the confusing/unclear/ambiguous cases come from an incomplete
implementation of @property and an unnecessary conflation with normal
functions. A @property function should not be treated like a normal
function. It turns the function into a variable-like entity that *no
longer acts like a function to the outsider*. Neither should normal
functions for whatever strange reasoning be conflated with @property
functions, because functions are not variables.

It's actually very straightforward once you remove all the unnecessary
conflations, and disregard, for the time being, the problems in the
current implementation.


T

-- 
There is no gravity. The earth sucks.