View mode: basic / threaded / horizontal-split · Log in · Help
December 11, 2011
Re: Fixing const arrays
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.
December 11, 2011
Re: Fixing const arrays
On 12/11/2011 1:54 AM, Walter Bright wrote:
> Try the new beta
> http://ftp.digitalmars.com/dmd2beta.zip
WHOA nice, the reduce() example worked!! :D Thanks for taking the time 
to fix it!
I'll post if I come across similar/related problems. :)
December 11, 2011
Re: Fixing const arrays
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/
December 11, 2011
Re: Fixing const arrays
> 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.
December 11, 2011
Re: Fixing const arrays
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().
December 11, 2011
Re: Fixing const arrays
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
December 11, 2011
Re: Fixing const arrays
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.
December 11, 2011
Re: Fixing const arrays
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).
December 11, 2011
Re: Fixing const arrays
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
December 11, 2011
Re: Fixing const arrays
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
1 2 3 4 5 6 7 8
Top | Discussion index | About this forum | D home