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.

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.
When I start a new project I'll definitely try using D for it, but right now my D escapade is on hold. :-(
--
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

> 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.
I agree.

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().

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.
Andrei

Le 11/12/2011 17:34, Andrei Alexandrescu a écrit :
> 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.
>> Andrei
I was thinking about sugesting this. So obviously, this is a +1 to me.

On 12/11/2011 05:34 PM, 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.
>> Andrei
+1. This also reduces template bloat, because IFTI wont create different instantiations when passed T, immutable(T), const(T).

On Sunday, December 11, 2011 14:54:27 Tobias Pankrath wrote:
> > 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.
> > I agree.
It was debated some time ago, and it ended up being a property. The fact that save is an action verb and not a noun automatically disqualifies it as a property IMHO, but it was made into a property, and we're pretty much stuck with it at some point. As far as what the function does, I don't think that it's a problem that it's a property, but it's not named like a property, so the situation with regards to save is not ideal, but it's too late now.
- Jonathan M Davis

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.
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.
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?
In theory, I think that stripping const and immutable from primitives at the top level could be a nice thing to have, but I'd be very concerned about how that would be implemented and what it would affect. We risk losing valuable type information and breaking existing code if it's not done right.
- Jonathan M Davis