View mode: basic / threaded / horizontal-split · Log in · Help
December 12, 2011
Re: Fixing const arrays
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/
December 12, 2011
Re: Fixing const arrays
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
December 12, 2011
Re: Fixing const arrays
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
December 12, 2011
Re: Fixing const arrays
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
December 12, 2011
Re: Fixing const arrays
On 12/12/11 6:24 AM, torhu wrote:
> save being a property is a stupid inconsistency.

I'm not so sure.

Andrei
December 12, 2011
Re: Fixing const arrays
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
December 12, 2011
Re: Fixing const arrays
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.
December 12, 2011
Re: Fixing const arrays
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.
December 12, 2011
Re: Fixing const arrays
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?
December 12, 2011
Re: Fixing const arrays
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
2 3 4 5 6 7 8 9 10
Top | Discussion index | About this forum | D home