On Fri, 22 Apr 2011 13:22:31 -0400, Steve Schveighoffer <schveiguy at yahoo.com> wrote:
>> From: Robert Jacques <sandford at jhu.edu>
[snip]
>> Forth, came the realization that in D2 'seconds' would probably be pure, which would cause s.seconds = 5 to be compiler error.
>
> No, it wouldn't be an error.  s.seconds(5) is exactly the same as TimeSpan.seconds(5), both would be callable as pure functions.  In other words, s isn't actually passed to the function, it's just used as a namespace.

I apologize, pure alone wouldn't be enough to cause a compiler error. I was thinking of the fact that DMD could/does error on expressions which do nothing. However, pure wouldn't be enough to let the compiler know 'seconds = 5' does nothing. It would probably take a combination of const/immutable + pure + nothrow, for DMD to detect that s.seconds = 5 could not possible produce useful work, and therefore should error.

On Fri, 22 Apr 2011 14:20:21 -0400, Robert Jacques <sandford at jhu.edu> wrote:

> On Fri, 22 Apr 2011 13:22:31 -0400, Steve Schveighoffer <schveiguy at yahoo.com> wrote:
>>> From: Robert Jacques <sandford at jhu.edu>
> [snip]
>>> Forth, came the realization that in D2 'seconds' would probably be pure, which would cause s.seconds = 5 to be compiler error.
>>
>> No, it wouldn't be an error.  s.seconds(5) is exactly the same as TimeSpan.seconds(5), both would be callable as pure functions.  In other words, s isn't actually passed to the function, it's just used as a namespace.
>
> I apologize, pure alone wouldn't be enough to cause a compiler error. I was thinking of the fact that DMD could/does error on expressions which do nothing. However, pure wouldn't be enough to let the compiler know 'seconds = 5' does nothing. It would probably take a combination of const/immutable + pure + nothrow, for DMD to detect that s.seconds = 5 could not possible produce useful work, and therefore should error.

P.S. On third thought, you'd really only need a const/immutable method, as assignment of const/immutable variables is invalid. (This would require a heuristic in DMD, etc). Also, given we can have static variables, static methods should also be able to be const/immutable. But since static variables are considered global state, perhaps pure covers those use cases. Hmm... so maybe I was correct in that a strongly-pure function called with field syntax should always be an error.

Actually, I think you are right.? I wasn't thinking about dmd erroring on a statement that does nothing.? You'd have to assign something to the expression, like:

auto x = s.seconds = 5;

Which still looks like it does something else, but is much less likely to occur.


You wouldn't need the parameter to be immutable, because the parameter is a value, making this a strong-pure function.


But this is still not an argument against strict properties.? I only bring up this example because it's the only case I've had where I had to change code due to a complaint that someone could use a function as a property.? Most cases you just say "sorry, the code isn't meant to be used that way, RTFM." But it would be better to avoid having the user complain in the first place.? It certainly gives a more polished feel for your library when you don't leave syntax holes like this open.

I look at the way a property/function is called as part of the 'human interface', i.e. it's part of the name of the function/property.? If you cannot control the human interface, you cannot control what the human thinks when he reads it.? Strict properties are all about freedom for the author to convey the correct means of using the library.? The author's only tool to enforce the interface is the compiler.? It's in the same vein as static typing -- yes, it's restrictive, but restriction gives you less room for errors.

Another analogy I like to draw upon is casing.? What if D's casing was insensitive?? That is, ReadValue is the same thing as readValue and readvalue .? There are probably many people who would love to always use their learned conventions for calling your code (e.g. I always make methods upper case), but then someone comes along and types in reAdvalue (my super-uncreative brain can't come up with a clever example to show something worse, but you get the idea).? The name is the same, but the casing makes all the difference to interpreting what it means!? Like it or not, the same thing applies to things like:

writeln = "hello";

Even though we know this is not the right way to call it, the compiler doesn't give an error to enforce the semantics.


-Steve



----- Original Message -----
> From: Robert Jacques <sandford at jhu.edu>
> To: Discuss the phobos library for D <phobos at puremagic.com>
> Cc:
> Sent: Friday, April 22, 2011 2:55 PM
> Subject: Re: [phobos] Time to get ready for the next release
> 
> On Fri, 22 Apr 2011 14:20:21 -0400, Robert Jacques <sandford at jhu.edu> wrote:
> 
>>  On Fri, 22 Apr 2011 13:22:31 -0400, Steve Schveighoffer
> <schveiguy at yahoo.com> wrote:
>>>>  From: Robert Jacques <sandford at jhu.edu>
>>  [snip]
>>>>  Forth, came the realization that in D2 'seconds' would
> probably be pure, which would cause s.seconds = 5 to be compiler error.
>>> 
>>>  No, it wouldn't be an error.? s.seconds(5) is exactly the same as
> TimeSpan.seconds(5), both would be callable as pure functions.? In other words, s isn't actually passed to the function, it's just used as a namespace.
>> 
>>  I apologize, pure alone wouldn't be enough to cause a compiler error. I
> was thinking of the fact that DMD could/does error on expressions which do nothing. However, pure wouldn't be enough to let the compiler know 'seconds = 5' does nothing. It would probably take a combination of const/immutable + pure + nothrow, for DMD to detect that s.seconds = 5 could not possible produce useful work, and therefore should error.
> 
> P.S. On third thought, you'd really only need a const/immutable method, as
> assignment of const/immutable variables is invalid. (This would require a
> heuristic in DMD, etc). Also, given we can have static variables, static methods
> should also be able to be const/immutable. But since static variables are
> considered global state, perhaps pure covers those use cases. Hmm... so maybe I
> was correct in that a strongly-pure function called with field syntax should
> always be an error.
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>

On Fri, Apr 22, 2011 at 3:26 PM, Steve Schveighoffer <schveiguy at yahoo.com>wrote:

>  Like it or not, the same thing applies to things like:
>
> writeln = "hello";
>
> Even though we know this is not the right way to call it, the compiler doesn't give an error to enforce the semantics.
>
>
> -Steve
>

Ok, but just because you can do something utterly stupid like this doesn't mean you should.  You can also do the following even though it's a terrible idea, because it's impossible for the compiler to reject every terrible idea without rejecting some good ideas:

import std.random;

// Overwrite random memory locations with random data until the program
// crashes
void main() {
    while(true) {
         auto num = uniform(0, int.max);
         auto ptr = cast(int*) num;
         *ptr = uniform(0, int.max);
    }
}

Again, I'd be more sympathetic to your point of view if making these changes didn't also break existing code.  For me this is the tiebreaker.  I have already designed a whole API around methods-as-properties.  I'm sure having tons of code break will be very aggravating to a lot of people.  Given the weak arguments put forth in favor of strict semantics, I can't bring myself to say that breaking not only existing code but whole existing API designs is justified.

BTW, as far as your argument about static typing, this may be a fundamental disagreement between us.  I don't like static typing, but consider it a necessary evil in exchange for performance and the ability to do low-level work.  Therefore, I want only as much static typing as is necessary for these to be possible.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20110422/6f34ca30/attachment.html>

Unlike your example, writeln = "hello" is actually valid, correct code.? That is, it's not utterly stupid, it's just utterly ugly (to you and me).? If someone wants to call writeln that way because they like the "style", then that's their choice.? I see no difference from what you propose.


It's not about the compiler rejecting terrible code because it thinks the code is terrible, it's about the compiler rejecting terrible code because the library author thinks it's terrible.? That is, the library author can decide how you should use their code, just like he decides which functions are private and public.

I understand your frustration for having existing code break.? All I can offer is at least the broken code will provide an error and line number where you can fix it.

There are many people who refuse to move to D2 because of the const semantics.? They say "my code works fine without const, I don't see why I should have to change it.? D2 const sucks!"? But const can be a very useful thing *if* you use it correctly.? So it's a tradeoff.? I feel the property syntax as it currently stands is out of control, bug prone, and needs to be reined in.? You feel it's just what you need, and you use it to great effect.? Nobody is 100% right, but with strict properties, things look better because you have the freedom to name your methods without worry that they are misused.? I see it as a huge gain.

I also don't like the new operator overloading scheme in D2, since there are oodles of problems with template methods and classes, but they are much more powerful than the old method.? Since the old methods are unofficially still there, I have something to fall back on for dcollections, but I expect some day to have to drop all references to the old operator overloading functions.? Is it frustrating?? Yes.? Does it seem pointless?? Yes.? But my single opinion and my library cannot be the reason that an obviously better system isn't adopted.


-Steve




>________________________________
>From: David Simcha <dsimcha at gmail.com>
>To: Discuss the phobos library for D <phobos at puremagic.com>
>Sent: Friday, April 22, 2011 3:39 PM
>Subject: Re: [phobos] Time to get ready for the next release
>
>
>
>
>
>On Fri, Apr 22, 2011 at 3:26 PM, Steve Schveighoffer <schveiguy at yahoo.com> wrote:
>
>?Like it or not, the same thing applies to things like:
>>
>>writeln = "hello";
>>
>>Even though we know this is not the right way to call it, the compiler doesn't give an error to enforce the semantics.
>>
>>
>>-Steve
>>
>Ok, but just because you can do something utterly stupid like this doesn't mean you should.? You can also do the following even though it's a terrible idea, because it's impossible for the compiler to reject every terrible idea without rejecting some good ideas:
>
>import std.random;
>
>// Overwrite random memory locations with random data until the program
>// crashes
>void main() {
>??? while(true) {
>? ?? ??? auto num = uniform(0, int.max);
>? ? ? ?? auto ptr = cast(int*) num;
>? ? ? ?? *ptr = uniform(0, int.max);
>??? }
>}
>
>Again, I'd be more sympathetic to your point of view if making these changes didn't also break existing code.? For me this is the tiebreaker.? I have already designed a whole API around methods-as-properties.? I'm sure having tons of code break will be very aggravating to a lot of people.? Given the weak arguments put forth in favor of strict semantics, I can't bring myself to say that breaking not only existing code but whole existing API designs is justified.
>
>BTW, as far as your argument about static typing, this may be a fundamental disagreement between us.? I don't like static typing, but consider it a necessary evil in exchange for performance and the ability to do low-level work.? Therefore, I want only as much static typing as is necessary for these to be possible.
>
>_______________________________________________
>phobos mailing list
>phobos at puremagic.com
>http://lists.puremagic.com/mailman/listinfo/phobos
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20110422/35fbe3aa/attachment-0001.html>

On Fri, Apr 22, 2011 at 4:28 PM, Steve Schveighoffer <schveiguy at yahoo.com>wrote:

> I also don't like the new operator overloading scheme in D2, since there are oodles of problems with template methods and classes, but they are much more powerful than the old method.  Since the old methods are unofficially still there, I have something to fall back on for dcollections, but I expect some day to have to drop all references to the old operator overloading functions.  Is it frustrating?  Yes.  Does it seem pointless?  Yes.  But my single opinion and my library cannot be the reason that an obviously better system isn't adopted.
>
> -Steve
>
>
This is fixable in one line per class:

mixin(oldOperatorOverloading);

Such a mixin would automagically create new style operator overloads that forward to the old ones.  It would be trivial, though somewhat tedious, to write, but once written the problem would be solved forever.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20110422/1bf89c0b/attachment.html>

On Fri, Apr 22, 2011 at 4:28 PM, Steve Schveighoffer <schveiguy at yahoo.com>wrote:

> Unlike your example, writeln = "hello" is actually valid, correct code. That is, it's not utterly stupid, it's just utterly ugly (to you and me). If someone wants to call writeln that way because they like the "style", then that's their choice.  I see no difference from what you propose.
>
> It's not about the compiler rejecting terrible code because it thinks the code is terrible, it's about the compiler rejecting terrible code because the library author thinks it's terrible.  That is, the library author can decide how you should use their code, just like he decides which functions are private and public.
>
>
Right, but I don't *want* the power to control this.  I don't *want *to be forced to decide such things for my users.  I want my users to be able to do as they see fit.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20110422/82b47948/attachment.html>

It doesn't work for me.? See:

http://d.puremagic.com/issues/show_bug.cgi?id=4174 http://d.puremagic.com/issues/show_bug.cgi?id=4182

I should say, 4174 is due to using interfaces.

-Steve




>________________________________
>From: David Simcha <dsimcha at gmail.com>
>To: Steve Schveighoffer <schveiguy at yahoo.com>; Discuss the phobos library for D <phobos at puremagic.com>
>Sent: Friday, April 22, 2011 4:32 PM
>Subject: Re: [phobos] Time to get ready for the next release
>
>
>
>
>
>On Fri, Apr 22, 2011 at 4:28 PM, Steve Schveighoffer <schveiguy at yahoo.com> wrote:
>
>I also don't like the new operator overloading scheme in D2, since there are oodles of problems with template methods and classes, but they are much more powerful than the old method.? Since the old methods are unofficially still there, I have something to fall back on for dcollections, but I expect some day to have to drop all references to the old operator overloading functions.? Is it frustrating?? Yes.? Does it seem pointless?? Yes.? But my single opinion and my library cannot be the reason that an obviously better system isn't adopted.
>>
>>
>>
>>-Steve
>>
>>
>
>This is fixable in one line per class:
>
>mixin(oldOperatorOverloading);
>
>Such a mixin would automagically create new style operator overloads that forward to the old ones.? It would be trivial, though somewhat tedious, to write, but once written the problem would be solved forever.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20110422/5316cc02/attachment.html>

Then give them both options.? You can still do this with strict properties, you just have to name the functions something different.

-Steve




>________________________________
>From: David Simcha <dsimcha at gmail.com>
>To: Discuss the phobos library for D <phobos at puremagic.com>
>Sent: Friday, April 22, 2011 4:35 PM
>Subject: Re: [phobos] Time to get ready for the next release
>
>
>
>
>
>On Fri, Apr 22, 2011 at 4:28 PM, Steve Schveighoffer <schveiguy at yahoo.com> wrote:
>
>Unlike your example, writeln = "hello" is actually valid, correct code.? That is, it's not utterly stupid, it's just utterly ugly (to you and me).? If someone wants to call writeln that way because they like the "style", then that's their choice.? I see no difference from what you propose.
>>
>>
>>
>>It's not about the compiler rejecting terrible code because it thinks the code is terrible, it's about the compiler rejecting terrible code because the library author thinks it's terrible.? That is, the library author can decide how you should use their code, just like he decides which functions are private and public.
>>
>Right, but I don't want the power to control this.? I don't want to be forced to decide such things for my users.? I want my users to be able to do as they see fit.
>
>_______________________________________________
>phobos mailing list
>phobos at puremagic.com
>http://lists.puremagic.com/mailman/listinfo/phobos
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20110422/2dbc46cb/attachment-0001.html>

On Fri, 22 Apr 2011 16:28:35 -0400, Steve Schveighoffer <schveiguy at yahoo.com> wrote:
> Unlike your example, writeln = "hello" is actually valid, correct code. That is, it's not utterly stupid, it's just utterly ugly (to you and me).  If someone wants to call writeln that way because they like the "style", then that's their choice.  I see no difference from what you propose.

Umm, Steve,  writeln = "hello" hasn't been valid, correct code for a long, long time. Please don't propagate this misconception any more.