On Friday, February 15, 2013 23:49:53 monarch_dodra wrote:
> On Friday, 15 February 2013 at 22:06:55 UTC, Steven Schveighoffer
> 
> wrote:
> > With opcmp:
> > 
> > int opCmp(int a, int b)
> > {
> > 
> > return a - b;
> > 
> > }
> 
> Genius!
> 
> Now I feel bad for every time I've done integral opCmp with double ternary operators :(

Except that you have to worry about overflow if you use subtraction, so it's actually a bad idea in the general case.

- Jonathan M Davis

On Fri, 15 Feb 2013 17:49:53 -0500, monarch_dodra <monarchdodra@gmail.com> wrote:

> On Friday, 15 February 2013 at 22:06:55 UTC, Steven Schveighoffer wrote:
>> With opcmp:
>>
>> int opCmp(int a, int b)
>> {
>>    return a - b;
>> }
>
> Genius!
>
> Now I feel bad for every time I've done integral opCmp with double ternary operators :(

Actually, I'm not as smart as you think ;)

There needs to be some extra checking, possibly with the carry flag.

For example:

0x70000000 - (-0x70000000)

would be less than zero as a resulting integer.

But it would work with shorts or bytes!

In any case, the example was bad, the point that which is better depends on the situation is still correct.

-Steve

On Fri, 15 Feb 2013 18:41:51 -0500, Steven Schveighoffer <schveiguy@yahoo.com> wrote:

> There needs to be some extra checking, possibly with the carry flag.
>

And further to that point, my generated assembly for a < b also is similarly flawed, so it still may be better to do opCmp.

-Steve

Steven Schveighoffer:

> Actually, I'm not as smart as you think ;)
>
> There needs to be some extra checking, possibly with the carry flag.
>
> For example:
>
> 0x70000000 - (-0x70000000)
>
> would be less than zero as a resulting integer.
>
> But it would work with shorts or bytes!

I remember a page about such problem in the old D wiki. I was unable to find it inside the new D wiki.

Bye,
bearophile

On Friday, 15 February 2013 at 23:41:50 UTC, Steven Schveighoffer wrote:
> In any case, the example was bad, the point that which is better depends on the situation is still correct.

The compiler has to do something with "a<b". I would hope for a fundamental type it can avoid the lowering and just do whatever assembly is optimal. For a non-fundamental type, what is the case where (a.opCmp(b)<0) is more optimal than a comparable (a.opLess(b))?

It is easy to create an inefficient implementation of opCmp that calls "<" twice.

struct S {
   string s;
   int opCmp ( const ref S other ) {
     if ( s<other.s ) {
       return -1;
     } else if ( other.s<s ) {
       return 1;
     } else {
       return 0;
     }
   }
}

My point was, you can use compile time reflection to generate a suitable opCmp that uses s.opCmp if it exists or does the long version of two comparisons if not.

Thanks
Dan

On Friday, 15 February 2013 at 20:58:30 UTC, Jonathan M Davis wrote:
>
> I should probably add that bringing up discussions on how to solve problems in
> the language can be of benefit, because they often result in good discussions
> that help lead toward a solution, and that can lead towards that solution
> ending up in the language (and depending on the discussion Andrei and/or
> Walter will get involved). But simply asking them about the state of things or
> essentially contronting them and trying to get them to give official statements
> on their plans doesn't generally work. If nothing else, they simply don't
> generally say what they're planning to do before they've actually decided on
> it. They might start discussions to discuss something that they're
> considering, but they're unlikely to state any kind of actual plans before
> they've actually decided, which generally means no official statements about
> what's coming or planned.
>
> - Jonathan M Davis

Well, that is a somewhat passive yet diplomatic stance. If the suggestion is - "get involved, suggest a fix or a solution and maybe you'll get your answers" that is reasonable. But for my part, I am not a language developer - just a language user and fan of D who is betting on D by using it for my livelihood. Regarding postblits - you've mentioned several times that Andrei and Walter have discussed and have a solution in the works. Does it make sense to go do a DIP or something just to illicit feedback on a topic? You have some of the most helpful responses I've seen on the group - extremely detailed and accurate. Thanks. However, being in the know you sometimes you let slip a little bit here and there that causes me to give pause and at a minimum want to get more information. Like "And Walter was actually arguing at one point for making it illegal (probably by getting rid of postblit all together - I don't remember the details)".

It is not unreasonable for users to want to know what is the future direction for a certain at risk feature. Regarding a suggestion for postblit/copy ctor to get things going here is mine:

- Implement copy constructors for structs. Allow for overloading on 'this' and 'const this', but no qualifier on the constructor itself.
- Allow the user to @disable copy constructors.
- Provide for a default copy constructor that does regular copies of fundamental types, shallow copies of arrays and associative arrays,  and calls corresponding copy constructors (or postblits during some grace period).

In terms of migration path:

- Allow the struct designer to choose to use either postblit or copy constructor but not both. For the case of using them to provide deep copy semantics the approaches are different. For postblits you are asking - "what fields do I need to copy" with the comfort of knowing all other fields were already copied with the blit. For copy constructors it is different because you have to think about all fields since a blit will not have happened first. To ease the transition provide the ability for the copy constructor to call blitSourceIntoThis(source).

- Leave postblits alone. Allow them to continue as is and phase them out 1 or more years after successful implementation of copy constructors

- Often the only purpose of the copy constructor is to do a deep copy. This could easily be provided by the compiler or phobos. Further, consider standardizing on the ".dup" and ".idup" conventions for this purpose.

Thanks
Dan