November 19, 2012
On 11/19/12 12:30 PM, Michel Fortin wrote:
> On 2012-11-19 06:52:11 +0000, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> said:
>
>> On 11/19/12 1:02 AM, Rob T wrote:
>>> So what's up with @property?
>>
>> It's a mistake on top of another. We need to redesign it to such that
>> the keyword '@property' is only required in cases that otherwise would
>> be ambiguous (functions returning functions).
>
> …or functions returning a type with an opCall.
>
> What about template functions with a parametrized return type that will
> sometime be ambiguous and sometime not depending on the template
> parameters?
>

Let's put all of these cases in a DIP so we can analyze them.

Thanks,

Andrei
November 19, 2012
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.
November 19, 2012
11/19/2012 9:58 PM, monarch_dodra пишет:
> On Monday, 19 November 2012 at 17:42:28 UTC, Dmitry Olshansky wrote:
>> 11/19/2012 7:18 PM, monarch_dodra пишет:
>>> On Monday, 19 November 2012 at 14:58:29 UTC, Andrei Alexandrescu wrote:
>>>> On 11/19/12 4:01 AM, monarch_dodra wrote:
>>>>> I kind of agree with Jonathan here. @property really shines when you
>>>>> want to "add" an attribute to a struct.
>>>>
>>>> I kind of agree with him, too, but it would be a mistake to not reckon
>>>> a change in dynamics. UFCS makes all those extra parens just awkward,
>>>> and people will vote with their code regardless whether some
>>>> particular viewpoint from some particular angle considers the approach
>>>> backwards.
>>>>
>>>> Andrei
>>>
>>> One of the things that we may want to take into account, is that
>>> -property prevents any existing function from migrating to/from
>>> property. For example, if we want to make "retro" a property, we can't
>>> without breaking any and all UFCS usage of retro.
>>>
>>
>> The major problem about @property enforcement as it stands is that it
>> breaks the duality of things like retro:
>> a.retro
>> vs
>> retro(a)
>>
>> Both should be allowed as it's a matter of taste that shouldn't be
>> enforced. A lot of new code uses a.retro and a lot of older code uses
>> retro(a).
>>
>> If retro is property then only the first one compiles
>> If retro is a function then only the second one compiles.
>>
>> Which obviously means @property has to be reconsidered.
>
> Hum... Perhaps you meant:
> a.retro
> vs
> a.retro()

This one too.

> Because "retro(a)" works regardless of the property.

Hm.. being a while since I tried to use -property switch. I thought it was also disallowed. Not so bad then I guess.

Looking forward to DIP21.


-- 
Dmitry Olshansky
November 19, 2012
On Monday, 19 November 2012 at 18:02:06 UTC, Adam D. Ruppe wrote:
> On Monday, 19 November 2012 at 15:01:36 UTC, Andrei Alexandrescu wrote:
>> Would you please start a DIP with a paste of this idea?
>
> here it is:
> http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP21

Thanks a lot for doing this! It's a pity that the last bigger discussion didn't lead anywhere, I don't think there was much disagreement. Hopefully, having a DIP to discuss will catalyze the process a bit.

David
November 19, 2012
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?).

 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).
November 19, 2012
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...
November 19, 2012
On Monday, November 19, 2012 21:42:25 Dmitry Olshansky wrote:
> 11/19/2012 7:18 PM, monarch_dodra пишет:
> > On Monday, 19 November 2012 at 14:58:29 UTC, Andrei Alexandrescu wrote:
> >> On 11/19/12 4:01 AM, monarch_dodra wrote:
> >>> I kind of agree with Jonathan here. @property really shines when you want to "add" an attribute to a struct.
> >> 
> >> I kind of agree with him, too, but it would be a mistake to not reckon a change in dynamics. UFCS makes all those extra parens just awkward, and people will vote with their code regardless whether some particular viewpoint from some particular angle considers the approach backwards.
> >> 
> >> Andrei
> > 
> > One of the things that we may want to take into account, is that -property prevents any existing function from migrating to/from property. For example, if we want to make "retro" a property, we can't without breaking any and all UFCS usage of retro.
> 
> The major problem about @property enforcement as it stands is that it
> breaks the duality of things like retro:
> a.retro
> vs
> retro(a)
> 
> Both should be allowed as it's a matter of taste that shouldn't be enforced. A lot of new code uses a.retro and a lot of older code uses retro(a).
> 
> If retro is property then only the first one compiles
> If retro is a function then only the second one compiles.
> 
> Which obviously means @property has to be reconsidered.

The thing is that if @property is really an abstraction for variables, then it _doesn't_ make sense to allow both, because it's _not_ a matter of taste. Either it's a variable, or it's a function. Not both. And if it's a variable, then obviously no parens should be used with it. And if it's a function, then obviously parens should be used with it.

If you're viewing it as just a way to not have to use parens on functions, then that's something else entirely. And if that's what we're looking to support, then using @property for that makes no sense at all.

Personally, I hate the fact it's legal to have any kind of optional parens. I think that it's incredibly sloppy and goes against the abstractions of variables and functions. I'm all for forcing the full set of parens in a long chain of UFCS. But clearly plenty of other folks don't agree.

Because of all of those folks, it may make sense to make it so that parens are optional on functions but are outright verboten on @property functions. That way, anyone wanting to use @property for actual properties can do so with proper enforcement, but those who want to just leave parens off of normal function calls can. I really don't like the idea, but at this point, I think that it's fairly clear that there are a lot of people who _like_ the sloppy nature of being able to leave parens off much as a number of the rest of us hate it.

- Jonathan M Davis
November 19, 2012
On Monday, 19 November 2012 at 20:04:24 UTC, Jonathan M Davis wrote:
> The thing is that if @property is really an abstraction for variables, then it
> _doesn't_ make sense to allow both, because it's _not_ a matter of taste.
> Either it's a variable, or it's a function. Not both. And if it's a variable,
> then obviously no parens should be used with it. And if it's a function, then
> obviously parens should be used with it.

That makes perfect sense to me if that's what the meaning of @property is supposed to be, and if so then it can constrain the usage to that of a variable, which currently is not the case.

> If you're viewing it as just a way to not have to use parens on functions,
> then that's something else entirely. And if that's what we're looking to
> support, then using @property for that makes no sense at all.

That makes sense to me as well, and indicates that the @property topic is getting mixed up with another topic, which concerns the optional use of () for empty parameter lists.

What may be forgotten, is that we currently have the ability to not only drop the (), but also to perform optional assignments, eg Foo = 23;, without defining a function Foo to be @property.

In one case we're talking about variable abstractions, and in another case we're talking about simply making () optional, these are two entirely separate topics that are mangled up together.

I think you understand this already, but perhaps not everyone else does.

To further complicate things, I find that when deciding to define a function as @property or not is like trying to decide if Pluto is a planet or not, it's often not clear which way you should go, and that may be why I really did enjoy not having to specify @property to make use of the semantics it (was supposed to) provide when and where I saw fit to do so.

> Personally, I hate the fact it's legal to have any kind of optional parens. I
> think that it's incredibly sloppy and goes against the abstractions of
> variables and functions. I'm all for forcing the full set of parens in a long
> chain of UFCS. But clearly plenty of other folks don't agree.

I seriously don't think you should try to constrain coding style, instead it makes much more sense to provide the user with a means to constrain it themselves as they see fit. Look at languages that constrain coding style too much vs languages that don't, and consider the popularity among them.

My two cents :)

--rt


November 19, 2012
On Monday, November 19, 2012 22:04:02 Rob T wrote:
> I seriously don't think you should try to constrain coding style, instead it makes much more sense to provide the user with a means to constrain it themselves as they see fit. Look at languages that constrain coding style too much vs languages that don't, and consider the popularity among them.

Excep that i don't think that it's really a question of style. It's treating a function as if it were a variable, when it's not only not a variable, but it's not even acting like one. It's implying that the code has one set of semantics when it has another. Dropping parens when specifically creating a function which is intended to emulate a variable makes sense. But dropping parens just because you feel like it then makes a function look like a variable when it's not and not intended to even act like one. That violates the very difference between function and variable on even a conceptual level. It would be one thing to make a particular character or sequence of characters optional when doing so doesn't make it look like it's something else entirely  (e.g. optional braces don't make anything look like anything else - they just drop some characters, and they don't introduce any ambiguities in the process). But it's quite another to make those characters optional when they make one language construct look like another.

- Jonathan M Davis
November 19, 2012
On Monday, 19 November 2012 at 20:00:27 UTC, monarch_dodra wrote:
> 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.


That's EXACTLY what I'm saying.

    foo.property;

is ALWAYS wrong semantically speaking, regardless of what it _could_ or _happens_ to do if it was/is defined.
So even if popFront() was a property, my point would be that it should not be a property in the first place.



It's like saying you should be able to add integers and function pointers just because they're both integers underneath.

Sure, the machine can do it, but we disallow it because it makes no sense.

Ditto here.