@property

[deadalnix]

Le 04/08/2012 19:13, Adam D. Ruppe a écrit :
> So the existing -property in the compiler as absolutely worthless. It is
> semantically wrong.
>
> @property void function() func() {
> return { assert(0, "success"); };
> }
>
> void main() {
> func(); // should assert 0 success, doesn't
> auto dele = &func;
> dele(); // should assert 0 success, doesn't
> }
>
> Does the same thing with and without -property, and it is
> wrong both ways.
>

Note that something more is wrong.
func(); // Do something
auto dele = &func;
dele(); // Expected to do the same thing, even if we passed throw & in 
the middle.

The whole thing is f***ed up IMO. (and I've made some work on SDC on the 
subject, the & is really convoluted to implement).

> When we look back at the test code:
>
> func(); // should assert 0 success, doesn't
> auto dele = &func;
>

auto dele = func;

> These two lines both currently refer to the getter function
> itself. We want the getter function to be completely invisible
> to all other code.
>
>
> This should be rewritten kinda like if this were in the code:
> #define func (func())
>
>
> This would also fix things like
>
> func += 10;
>
> if func returned a ref int.
>
> What SHOULD happen:
>
> callexp.d(18): Error: function expected before (), not func() of type int
> callexp.d(20): Error: function expected before (), not func() of type int
>

+1

> Or something like that. Since @property ref int func() is supposed to be
> interchangable for a plain int func;, no special enforcement of
> @property syntax is required: it is illegal to call an int like a
> function, and func is an int as far as the outside world is concerned.
>

+1

> 1) Do we all agree that @properties should be interchangeable for plain
> variables of the return value's type in all contexts? That is, if I can
> make this work with a pull request, is that going to be acceptable?
>

Except for that & thing, 100% agreed.