On Friday, February 15, 2013 21:16:51 Namespace wrote:
> > They're not going to do that until they've decided, and AFAIK,
> > they haven't.
> > Attempting to essentially confront them and get them to say
> > what they plan to
> > do generally doesn't get you anywhere - especially since
> > they're unlikely to
> > say much until they actually are planning to do it, and it's
> > usually the case
> > that no decision has been made.
> > 
> > - Jonathan M Davis
> 
> I did not mean the const& thing. This is hopeless and will
> certainly take some months or years.
> My post was based on "[...] probably by getting rid of postblit
> all together.".

I know. And my answer is the same. There's nothing special about the const& issue and how that's going. That's how it pretty much always goes. Until it becomes a priority for Walter, it'll go nowhere. Sometimes, if someone makes it a priority and implements it (creating a pull request for it), then that solves the problem, but sometimes that's still not enough, because Walter needs to sort out whether it's the direction that we want to go, which means making it a priority to sort that out, which means that the pull request sits around for a while and may or may not make it in. Bug fixes and more minor language changes do get merged all the time, but if a language change is significant enough, it generally requires that Walter spend some time on it and make a decision on it (even if he's not implementing the changes), and he's generally very slow about that if it's not near the top of his list of priorities.

- Jonathan M Davis

On Friday, February 15, 2013 21:37:46 Jonathan M Davis wrote:
> On Friday, February 15, 2013 21:16:51 Namespace wrote:
> > > They're not going to do that until they've decided, and AFAIK,
> > > they haven't.
> > > Attempting to essentially confront them and get them to say
> > > what they plan to
> > > do generally doesn't get you anywhere - especially since
> > > they're unlikely to
> > > say much until they actually are planning to do it, and it's
> > > usually the case
> > > that no decision has been made.
> > > 
> > > - Jonathan M Davis
> > 
> > I did not mean the const& thing. This is hopeless and will
> > certainly take some months or years.
> > My post was based on "[...] probably by getting rid of postblit
> > all together.".
> 
> I know. And my answer is the same. There's nothing special about the const& issue and how that's going. That's how it pretty much always goes. Until it becomes a priority for Walter, it'll go nowhere. Sometimes, if someone makes it a priority and implements it (creating a pull request for it), then that solves the problem, but sometimes that's still not enough, because Walter needs to sort out whether it's the direction that we want to go, which means making it a priority to sort that out, which means that the pull request sits around for a while and may or may not make it in. Bug fixes and more minor language changes do get merged all the time, but if a language change is significant enough, it generally requires that Walter spend some time on it and make a decision on it (even if he's not implementing the changes), and he's generally very slow about that if it's not near the top of his list of priorities.

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

Again: My intention was not const&.

And you're right, but there was so many discussions about const& (since dmd 2.057; also in the last few days) and as every discussion here: after page 2 is the topic changed.
I'm also very sure that neither Walter nor Andrei see a (important) reason for something similar as const& because they don't need it. And if you don't need something, the priority for such thing is very low.
So everything we can do (after that much requests and discussions) is to wait what and when they will decide something.
I count the versions.

On Fri, 15 Feb 2013 13:14:21 -0500, Dan <dbdavidson@yahoo.com> wrote:

> When you say things like "Andrei was considering phasing out postblits..." I get nervous. Can we please have some comments from Andrei/Walter about what the plans are? I'm not asking for the ultimate solution - just to know the general direction and where this issue stands at present. Is there anything any of us can do to help move this forward?

I think the plan was to *assume* postblits were inexpensive, not to disallow them.

-Steve

On Friday, February 15, 2013 22:41:24 Namespace wrote:
> Again: My intention was not const&.

I know. What I'm saying applies in general.

> And you're right, but there was so many discussions about const&
> (since dmd 2.057; also in the last few days) and as every
> discussion here: after page 2 is the topic changed.
> I'm also very sure that neither Walter nor Andrei see a
> (important) reason for something similar as const& because they
> don't need it. And if you don't need something, the priority for
> such thing is very low.
> So everything we can do (after that much requests and
> discussions) is to wait what and when they will decide something.
> I count the versions.

They definitely agree that it's a problem. They just don't see it as having as high a priority as you do. For instance, as far as ref-related problems go, the issue that DIP 25 covers is something that they consider to be a much bigger issue (since it deals with @safe and SafeD). It'll be fixed though. It's just a question of how and when.

- Jonathan M Davis

On Friday, February 15, 2013 16:53:36 Steven Schveighoffer wrote:
> On Fri, 15 Feb 2013 13:14:21 -0500, Dan <dbdavidson@yahoo.com> wrote:
> > When you say things like "Andrei was considering phasing out postblits..." I get nervous. Can we please have some comments from Andrei/Walter about what the plans are? I'm not asking for the ultimate solution - just to know the general direction and where this issue stands at present. Is there anything any of us can do to help move this forward?
> 
> I think the plan was to *assume* postblits were inexpensive, not to disallow them.

Yes, but as I recall, in discussions on const and postblit, Andrei made a comment about how postblit hadn't really worked out and we need copy constructors (in which case, we'd move to normally using copy constructors as the norm). But I don't believe that Andrei suggested getting rid of postblit completely (due to the code breakage it would cause if nothing else), and while I think that Walter and Andrei would deal with the postblit issue very differently if they were to start over, there are no plans at present to get rid of it.

- Jonathan M Davis

> They definitely agree that it's a problem. They just don't see it as having as
> high a priority as you do.
For me it is not a priority (anymore). I use C++ again.

> It's just a question of how and when.
>
> - Jonathan M Davis

Yes as I said: I count the versions. :)

On Fri, 15 Feb 2013 13:02:39 -0500, Dan <dbdavidson@yahoo.com> wrote:

> On Friday, 15 February 2013 at 17:42:30 UTC, Steven Schveighoffer wrote:
>> On Fri, 15 Feb 2013 12:11:55 -0500, monarch_dodra <monarchdodra@gmail.com> wrote:
>>
>>> Also keep in mind that "a < b" is implemented as two calls to "a.opCmp(b)", and "a.opCmp(b)" is itself usually implemented as two calls to "something < something else" (!)
>>
>> Huh?
>>
>> a < b is implemented as a.opCmp(b) < 0, not two calls to a.opCmp(b).
>
> Yes. But isn't opCmp still more work than just a<b?

It depends:

bool less(int a, int b)
{
  return a < b;
}

In assembly (pardon my ignorance of asm syntax):

ld a AX;
sub AX, b;
jneg L1; // jump if AX is less than zero
ld AX 0;
ret;
L1:
ld AX 1;
ret;

With opcmp:

int opCmp(int a, int b)
{
   return a - b;
}

Which simplifies the assembly significantly.  Note we don't have to shoehorn the result into a bool (which must be 0 or 1).

For other cases, such as a complex struct, less might be more efficient.  And really, when it comes down to it, it all depends on how you use it.  If most of the time you are using a < b or b < a, then less certainly can be more efficient (but not necessarily).  But if you want to do <=, ==, or  
>=, then opCmp can be more efficient.

-Steve

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 :(

On Fri, Feb 15, 2013 at 11:49:53PM +0100, 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 :(

You know that this is the origin of C's strcmp, right? Ever wondered why the C standard says that it returns <0, 0, or >0, as opposed to fixed values like -1, 0, 1?

Now you know why: it's because you could implement strcmp by repeatedly subtracting respective pairs of characters from the two strings, and return the result when it's no longer zero (in some CPUs' assembly language, this is a single branch-on-nonzero instruction). No need for extraneous overhead to convert the result of the comparison into fixed values of any sort.

D simply inherited from the genius of C's original designers. :)

Of course, this optimization may no longer be relevant in today's CPU's, due to pipelining, hazards, branch prediction, etc..


T

-- 
If creativity is stifled by rigid discipline, then it is not true creativity.