December 12, 2011
On Monday, 12 December 2011 at 16:09:03 UTC, Andrei Alexandrescu wrote:
> On 12/12/11 9:29 AM, Jakob Ovrum wrote:
>> On Monday, 12 December 2011 at 15:14:02 UTC, Andrei Alexandrescu wrote:
>>> On 12/12/11 9:07 AM, Jakob Ovrum wrote:
>>>> If the programmer sees just "r.save", he
>>>> doesn't know whether it's a field or a property, and he shouldn't need
>>>> to know, it should be fast and cheap, and return a consistent value. As
>>>> far as I know, this isn't always true for save
>>>
>>> Why? Save does behave like a field for the vast majority of structs.
>>>
>>> Andrei
>>
>> But save is an abstract interface function, its signature should reflect
>> all possible implementations.
>
> Same goes for many properties.
>
> Andrei

This is true, and many functions marked @property arguably shouldn't be. I think it's a little like the reason std.container.SList doesn't have a `length` property: the O(n) complexity doesn't match the interface `length` exposes (although formalised only in documentation/convention, not code).

If the standard library is allowed to assume `r.save` is a cheap operation, in the same fashion it's allowed to assume this(this) is cheap, then by all means, it makes sense as a property. The only remaining arguments against it are purely about the name, and I actually don't think that's relevant.

And just like you can still make a computationally expensive this(this) when absolutely necessary, you can do the same with save. If most reasonable uses of save have trivial performance, it might as well be a property.

I'm still a beginner with ranges, but by my understanding and by what some people made it sound like, reasonable uses of save include some which are non-trivial. If this is true, then removing @property from save encourages people to think more about what using it might mean for the code they are writing, which is definitely important.
December 12, 2011
On 12/12/11 3:16 PM, Andrei Alexandrescu wrote:
> On 12/12/11 9:09 AM, torhu wrote:
>> On 12.12.2011 15:43, Andrei Alexandrescu wrote:
>>> On 12/12/11 6:24 AM, torhu wrote:
>>>> save being a property is a stupid inconsistency.
>>>
>>> I'm not so sure.
>>>
>>> Andrei
>>
>> Why? As far as I can tell, it's inconsistent with what properties are
>> used like in other programming languages.
>
> Why?

My understanding is the properties are essentially meant to be indistinguishable from fields (hence the syntax). save() doesn't really act like a field.

Honestly though, I don't like properties at all (in any language). Function calls should not be hidden in syntax. IMO if your code contains so many get/set functions that properties save you time then you have bigger issues.
December 12, 2011
On Monday, December 12, 2011 09:16:53 Andrei Alexandrescu wrote:
> On 12/12/11 9:09 AM, torhu wrote:
> > On 12.12.2011 15:43, Andrei Alexandrescu wrote:
> >> On 12/12/11 6:24 AM, torhu wrote:
> >>> save being a property is a stupid inconsistency.
> >> 
> >> I'm not so sure.
> >> 
> >> Andrei
> > 
> > Why? As far as I can tell, it's inconsistent with what properties are used like in other programming languages.
> 
> Why?
> 
> > Saving something is an action,
> > which to me is a different concept.
> 
> So if we called .save .state or .current things would be any different?
> 
> > If it was called currentState
> > instead, that's what I'd call a property.
> 
> Ah. So now we're wasting time not on @property (as I'd predicted), but instead on what _names_ are suitable to work with it. I rest my case.
> 
> > Making something a property gives it certain connotations that break when it's called 'save'. That you can save the state of the range is a property, if you will. But the action of doing so is not a property. People are going to be surprised when save() doesn't compile. Isn't there something called the principle of least surprise?
> 
> I think we should only worry about surprising the uninitiated with how poorly designed the whole @property thing is.

A property is essentially an abstraction to treat a function like a member variable. As such, the naming conventions for a property should be equivalent to those for a variable - and that generally means nouns. save is not a noun. It's an action verb. So, yes, I think that it's a completely inappropriate name for a property. Something ilke state or current _would_ be appropriate names. However, at this point, I really don't think that it's worth arguing about.

If I were to change it, I'd probably just make save a function rather than renaming it, but if we did it, then there would be quite a bit of code that would have to be changed essentially over an argument over whether save is valid property name because it's not a noun. And while I _don't_ think that it's a valid property name, that's getting a bit petty given how much code would break.

I'm all for fixing names for camelcasing, because that really affects the consistency of the library and is almost always completely objective, but this is essentially an argument over the best name for a function, and that never has a clear answer. Yes, it's an issue of consistency on some level with regards to how we treat and name properties, but that's subjective enough that I don't expect us to ever be completely consistent on that.

- Jonathan M Davis
December 12, 2011
On Monday, December 12, 2011 08:46:18 Andrei Alexandrescu wrote:
> Insisting on the current property semantics was a sizeable mistake of this community, and I am sorry we gave into it.

Aside from the fact that the behavior of -property isn't the default, what's the problem with @property?

- Jonathan M Davis
December 12, 2011
On Monday, December 12, 2011 17:24:38 Jakob Ovrum wrote:
> I'm still a beginner with ranges, but by my understanding and by what some people made it sound like, reasonable uses of save include some which are non-trivial. If this is true, then removing @property from save encourages people to think more about what using it might mean for the code they are writing, which is definitely important.

Both save and postblit are supposed to be trivial. Algorithms generally assume that copying a range is O(1). There's nothing stopping save and postblit from costing more than that, but it's going to harm performance.

- Jonathan M Davis
December 13, 2011
On 12/12/11 1:12 PM, Jonathan M Davis wrote:
> On Monday, December 12, 2011 08:46:18 Andrei Alexandrescu wrote:
>> Insisting on the current property semantics was a sizeable mistake of
>> this community, and I am sorry we gave into it.
>
> Aside from the fact that the behavior of -property isn't the default, what's
> the problem with @property?

Other than it being completely useless, requiring more rote memorization, and fomenting time-wasting discussion? None.

Andrei
December 13, 2011
On Mon, 12 Dec 2011 19:00:35 -0500, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 12/12/11 1:12 PM, Jonathan M Davis wrote:
>> On Monday, December 12, 2011 08:46:18 Andrei Alexandrescu wrote:
>>> Insisting on the current property semantics was a sizeable mistake of
>>> this community, and I am sorry we gave into it.
>>
>> Aside from the fact that the behavior of -property isn't the default, what's
>> the problem with @property?
>
> Other than it being completely useless, requiring more rote memorization, and fomenting time-wasting discussion? None.

Wait, are we talking about @property or .save?

-Steve
December 13, 2011
On 12.12.2011 20:03, Jonathan M Davis wrote:
> On Monday, December 12, 2011 09:16:53 Andrei Alexandrescu wrote:
>>  On 12/12/11 9:09 AM, torhu wrote:
>>  >  On 12.12.2011 15:43, Andrei Alexandrescu wrote:
>>  >>  On 12/12/11 6:24 AM, torhu wrote:
>>  >>>  save being a property is a stupid inconsistency.
>>  >>
>>  >>  I'm not so sure.
>>  >>
>>  >>  Andrei
>>  >
>>  >  Why? As far as I can tell, it's inconsistent with what properties are
>>  >  used like in other programming languages.
>>
>>  Why?
>>
>>  >  Saving something is an action,
>>  >  which to me is a different concept.
>>
>>  So if we called .save .state or .current things would be any different?
>>
>>  >  If it was called currentState
>>  >  instead, that's what I'd call a property.
>>
>>  Ah. So now we're wasting time not on @property (as I'd predicted), but
>>  instead on what _names_ are suitable to work with it. I rest my case.
>>
>>  >  Making something a property gives it certain connotations that break
>>  >  when it's called 'save'. That you can save the state of the range is a
>>  >  property, if you will. But the action of doing so is not a property.
>>  >  People are going to be surprised when save() doesn't compile. Isn't
>>  >  there something called the principle of least surprise?
>>
>>  I think we should only worry about surprising the uninitiated with how
>>  poorly designed the whole @property thing is.
>
> A property is essentially an abstraction to treat a function like a member
> variable. As such, the naming conventions for a property should be equivalent
> to those for a variable - and that generally means nouns. save is not a noun.
> It's an action verb. So, yes, I think that it's a completely inappropriate
> name for a property. Something ilke state or current _would_ be appropriate
> names. However, at this point, I really don't think that it's worth arguing
> about.
>
> If I were to change it, I'd probably just make save a function rather than
> renaming it, but if we did it, then there would be quite a bit of code that
> would have to be changed essentially over an argument over whether save is
> valid property name because it's not a noun. And while I _don't_ think that
> it's a valid property name, that's getting a bit petty given how much code
> would break.

It's actually not 'save' being a noun that's the problem.  I just thought of a counter-example:

---
struct Foo {
    // the data
    Bar data[];

    // save data on shutdown?
    @property bool save() { return save_; }
    @property bool save(bool shouldShave) { return save_ = shouldSave; }

private:
    bool save_;
}
---
Not meant to be a realistic example, but save is fine as a property here.
December 13, 2011
On Tuesday, December 13, 2011 02:28:29 torhu wrote:
> It's actually not 'save' being a noun that's the problem. I just thought of a counter-example:
> 
> ---
> struct Foo {
> // the data
> Bar data[];
> 
> // save data on shutdown?
> @property bool save() { return save_; }
> @property bool save(bool shouldShave) { return save_ = shouldSave; }
> 
> private:
> bool save_;
> }
> ---
> Not meant to be a realistic example, but save is fine as a property here.

You can pretty much always come up with another function with a completely different purpose wit the same name.

Personally, the _only_ issue that I have with save is the fact that it's a property. The name save works well enough, and I can't think of anything that's better.

- Jonathan M Davis
December 13, 2011
On 13.12.2011 02:39, Jonathan M Davis wrote:
> On Tuesday, December 13, 2011 02:28:29 torhu wrote:
>> It's actually not 'save' being a noun that's the problem. I just
>> thought of a counter-example:
>>
>> --- struct Foo { // the data Bar data[];
>>
>> // save data on shutdown? @property bool save() { return save_; }
>> @property bool save(bool shouldShave) { return save_ = shouldSave;
>> }
>>
>> private: bool save_; } --- Not meant to be a realistic example, but
>> save is fine as a property here.
>
> You can pretty much always come up with another function with a
> completely different purpose wit the same name.
>
> Personally, the _only_ issue that I have with save is the fact that
> it's a property. The name save works well enough, and I can't think
> of anything that's better.

Yes, that's my opinion too.