@property needed or not needed?

[monarch_dodra]

On Monday, 19 November 2012 at 18:58:21 UTC, Era Scarecrow wrote:
> On Monday, 19 November 2012 at 18:21:55 UTC, Mehrdad wrote:
>> Why don't we just outright disallow expression-statements?
>>
>> After all,
>>
>>     2 + 3;
>>
>> should not be a valid statement, and so
>>
>>     foo.property;
>>
>> should not be, either.
>
>  Hmmm I would say if it's const/immutable and pure then it 
> would be an error (Side effects considered after all), 
> otherwise popFront may not work (it is a property I 
> believe...right?).

... wrong ;)

front is a property. popFront is a method.

>  So let's assume I make some struct to call the PC Speaker (for 
> whatever reason) then the following would break.
>
> struct PCSpeaker {
>   int dingsCalled;
>   void ding() @property {
>     dingsCalled++;
>     //some low level calls
>   }
> }
>
>  However if it was...
>
>   void ding() @property const pure
>
>  We know there's no side effects (and it can't modify the 
> struct), which then 'ding' could be an error on it's own 
> (Although without a return value that would make the signature 
> completely useless).

You could argue that since a property-function is meant to 
emulate an attribute, that calling one and doing nothing is 
*always* wrong, regardless of side effect. I mean, in the sense 
that doing the side effect would make no sense if there is no 
consumer for the side effect in question.

Back to retro: I think that it actually could be an attribute. In 
that case, when you write:

a.retro;

then there is no consumer, and it creates a compile error.

After thinking about more, I think a great definition of property 
would be "a function that returns a value that *must* be 
consumed". This would give it more power than the mere 
parenthesis, no-parenthesis status: Imagine "chain" 
property-attributed. In that case:

chain(a, b);

This would fail to compile, because there is no consumer for 
chain, regardless of side effect...