On 2011-12-12 12:38:09 +0000, "Jakob Ovrum" <jakobovrum@gmail.com> said:

> Furthermore, there weren't even a way to enforce the property syntax until lately, and it's still not enabled by default. If we change it right now, people still have time to adapt before the backwards-compatibility argument even kicks in (no matter how weak it is).

Indeed. As far as we know, there might be more people out there using save as a function than there are using save as a property. We don't know that because it isn't enforced and people will simply use what they feel is best.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

On Sun, 11 Dec 2011 06:16:33 -0500, Mehrdad <wfunction@hotmail.com> wrote:

> On 12/11/2011 2:56 AM, David Nadlinger wrote:
>> On 12/11/11 10:04 AM, Mehrdad wrote:
>>> On 12/11/2011 12:57 AM, Andrei Alexandrescu wrote:
>>>> I think you should write:
>>>>
>>>> auto copy = this.save;
>>>
>>> Ah good point, I forgot about that. Idk then.
>>> (You forgot the parentheses though. :P)
>>
>> No, it's correct like that, save() is a @property.
>>
>> Even though I recently updated Phobos to compile with -property enabled, I agree with Andrei here that in many cases there will be no perfect consensus whether a given member should be a @property or not, thus potentially adding an extra source of complexity, or rather annoyance.
>>
>> David
>
> Whoa what?! I didn't know save() is a @property. In that case I stand corrected. :-)
>
> Nevertheless, I think that makes no sense. :P If something isn't a "property" of something else, it shouldn't be marked as such.
>
> But there are more reasons than that...
>
> I have found Microsoft's guidelines for C# to be great for general usage of the word @property:
> http://msdn.microsoft.com/en-us/library/ms182181.aspx
>
> Specifically:
>
> "Properties should behave as if they are fields; if the method cannot, it should not be changed to a property.
> Methods are better than properties in the following situations:
>
> - Calling the method two times in succession creates different results.
> - The method performs a time-consuming operation. The method is perceivably slower than the time that is required to set or get the value of a field."
>
> Since both of these can be true for all but the most trivial kinds of ranges (e.g. file-system-related enumerators/ranges would very likely need to re-open a handle to a directory in order to traverse it, which is both relatively time-consuming AND returns a different result every time, and could even unexpectedly fail due to permission/connectivity issues), I don't think it makes sense for save() to be a @property.

The very definition of save is that it's only defined if it's fast.  So for example, a file range should not define save, it's an input range, not a forward range.

IMO, the whole concept of save is crap anyways.  I won't get into it again, search the NG archives if you want my opinion.

-Steve

On Sun, 11 Dec 2011 16:34:34 -0500, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> On Sunday, December 11, 2011 10:34:40 Andrei Alexandrescu wrote:
>> On 12/11/11 9:46 AM, dsimcha wrote:
>> > On 12/10/2011 4:47 PM, Andrei Alexandrescu wrote:
>> >> We decided to fix this issue by automatically shedding the top-level
>> >> const when passing an array or a pointer by value into a function.
>> >
>> > Really silly question: Why not do the same for primitives (int, float,
>> > char, etc.) or even structs without indirection? I've seen plenty of
>> > code that blows up when passed an immutable double because it tries to
>> > mutate its arguments. About 1.5 years ago I fixed a bug like this in
>> > std.math.pow().
>>
>> Yes, that would be good to do as well.
>
> Actually, that could be a problem for some stuff. It might be an acceptable
> problem, but it creates a problem nonetheless. What about containers? You can
> have arrays with immutable elements, but if you made it so that immutable int
> and int were the same as far as templates were concerned, then it would be
> impossible to have a container which held immutable elements. How big of a
> problem that is, I don't know, but I'd be concerned about some of the side
> effects.
>
> Another concern would be what would happen with primitives when they're inside
> of arrays. e.g.
>
> void func(T)(T[] arr)
>
> Having T lose its constness would be a big problem here.

T does not lose its constness here.  const(U[]) would go to const(U)[], which would then set T = const(U).

>
> Now, if we're talking only IFTI - such func(cast(immutable int)2) instantiates
> with int and func!(immutable int)(2) still instantiates with immutable int -
> and it's only for primitives by themselves (e.g. func above is unaffected),
> then it likely isn't a problem. But we need to really look at the side effects
> of trying to treat primitives as mutable in templates.

We are talking only IFTI.

Specifically, we are saying, for purposes of implying template parameters during IFTI, strip all the qualifiers from the pieces passed by value, as long as it doesn't affect any pieces passed by reference.

I bet doing this one thing would instantly trim at least 10k of bloat from an executable.  I'm looking at you, writeln.

>
> And if you're going to do that with primitives, it also opens up the question
> as to what to do with structs which are value types. Should they be treated
> the same?

Yes.

-Steve

On 2011-12-11 13:46, Michel Fortin wrote:
> On 2011-12-11 07:16:28 +0000, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> said:
>
>> On 12/10/11 5:20 PM, Michel Fortin wrote:
>>> Also seems strange to me that class references aren't included in that
>>> list, but then I though about how tail-const still doesn't work with
>>> objects. You'd need my const(Object)ref patch to make that work, and
>>> Walter hasn't taken time to look at it yet…
>>
>> Have you continued to use your fork in daily work? If so, how does it
>> pan out?
>
> Sadly, I'm not using D in my daily work these days. It's mostly C++ and
> Objective-C.
>
> I'd like to replace those two with D using my DMD/Objective-C fork, but
> it's still incomplete (lacks memory management), and DMD having no
> 64-bit support on OSX was a showstopper -- in fact, it still is for
> DMD/Objective-C which still lacks support for Apple's modern Objective-C
> runtime used on the 64-bit side. And my inability to make D for Xcode
> work with Xcode 4 is hampering the effort too.

It seems 64bit support will be available in the upcoming release (DMD for D1 has already been released).

-- 
/Jacob Carlborg

On 12/12/11 6:24 AM, torhu wrote:
> save being a property is a stupid inconsistency.

I'm not so sure.

Andrei

On 12/12/11 6:49 AM, Manu wrote:
> I think every opportunity should be taken to make important breaking
> changes while the community is as small as it is.

Changing from r.save to r.save() is NOT an important change. It makes no semantic difference, marks no progress, and has no consequence.

Insisting on the current property semantics was a sizeable mistake of this community, and I am sorry we gave into it.


Andrei

On Monday, 12 December 2011 at 12:38:10 UTC, Jakob Ovrum wrote:
> Furthermore, there weren't even a way to enforce the property syntax until lately, and it's still not enabled by default.

The real WTF is that someone decided @property should be used for
anything more than disambiguation.

On Monday, 12 December 2011 at 14:46:17 UTC, Andrei Alexandrescu wrote:
> On 12/12/11 6:49 AM, Manu wrote:
>> I think every opportunity should be taken to make important breaking
>> changes while the community is as small as it is.
>
> Changing from r.save to r.save() is NOT an important change. It makes no semantic difference, marks no progress, and has no consequence.
>
> Insisting on the current property semantics was a sizeable mistake of this community, and I am sorry we gave into it.
>
>
> Andrei

The whole point of a property to begin with is to make it look like a field, which has two important implications: improves interchangeability with function access vs a field, and exploits the user's intuition associated with accessing fields.

It is in light of the second consequence that it makes a difference. This is nothing new; the style guides for properties in C# operate on the same basic principle: if it looks like field access, it should behave like field access. 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, which means it breaks with the user's intuition.

I don't know whether or not this is an important change, but it *does* have consequence, and the current property semantics (as enforced with -property) are definitely meaningful. The old situation where you could write complete nonsense code like `std.file.read = "foo.txt";` is far worse.

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.  Saving something is an action, which to me is a different concept.  If it was called currentState instead, that's what I'd call a property.

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?

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