Re: Stroustrup is disappointed with D :(
On Tuesday, 22 September 2015 at 23:21:20 UTC, Steven
Schveighoffer wrote:
Yeah, but you can't do this in C++ though:
class D : B {
this()
{
writeln("derived is only now complete");
super();
}
}
I find the ability to control the construction order far more
important than virtual calls for base constructors.
You could do it in old C++ compilers, and some have a permissive
switch that allows you to do it, but you should not do it. It
leads to incorrect initialization and breaks encapsulation
(unsound typing). Forcing construction order is a Good Thing.
In Beta, the successor to Simula, all execution follows this
pattern:
this(){
begin_prepare_stuff();
subclass.this();
end_prepare_stuff();
}
This way the superclass defines what you can override which is
better for correctness.
Re: Stroustrup is disappointed with D :(
On Tuesday, 22 September 2015 at 22:14:56 UTC, deadalnix wrote: It is part of the .init, so the compiler would set it BEFORE calling the constructor. constructor can then call each other and rely on the fact that the vtable is initialized. We were discussing the cost if doing it like c++, where virtual calls during construction acts as if the object isn't subclassed. That way all object local member function calls can be devirtualized and inlined. In D we have to use the init method you mention.
Re: Stroustrup is disappointed with D :(
On 9/22/15 3:38 PM, Ali Çehreli wrote:
On 09/22/2015 11:58 AM, Tourist wrote:
"D disappointed me so much when it went the Java way".
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#to-do-unclassified-proto-rules
It's something about virtual calls, but I didn't understand what he
means. What does he mean?
It is about virtual calls in ctors and dtors. Here is the problem:
import std.stdio;
class B {
this() {
foo();
}
void foo() {
writeln("base");
}
}
class D : B {
this() {
writeln("derived is only now complete");
}
override void foo() {
writeln("derived");
}
}
void main() {
auto b = new D;
}
Although we are in the middle of consructing a D, the call foo() inside
B's ctor is dispatched to D's virtual foo() even though the D part of
the object has not been constructed yet. This is in contrast to C++,
where the object goes through multiple personalities during its
construction: First B, then D, etc.
The program above prints
derived
derived is only now complete
As can be seen, D.foo is called before D is ready for use.
Here is the equivalent C++ program:
#include
using std::cout;
class B {
public:
B() {
foo();
}
virtual ~B() {}
virtual void foo() {
cout << "base\n";
}
};
class D : public B {
public:
D() {
cout << "derived is only now complete\n";
}
virtual void foo() {
cout << "derived\n";
}
};
int main()
{
D d;
}
The output of the C++ program:
base
derived is only now complete
C++'s approach is better from the point of view of corretness. However,
it is slower because the object's vtbl pointer must be stamped several
times during construction. (I am not aware of available compiler
optimizations there.)
Ali
Yeah, but you can't do this in C++ though:
class D : B {
this()
{
writeln("derived is only now complete");
super();
}
}
I find the ability to control the construction order far more important
than virtual calls for base constructors.
-Steve
Re: Stroustrup is disappointed with D :(
On Tuesday, 22 September 2015 at 22:09:59 UTC, Ola Fosheim Grostad wrote: On Tuesday, 22 September 2015 at 21:25:06 UTC, deadalnix wrote: You can call super, so you need the virtual dispatch. I understand Ali's argument about setting local vtable before calling external functions in C++, but other than that it should be sufficient to set vtable in the new() or equivalent topmost call? It is part of the .init, so the compiler would set it BEFORE calling the constructor. constructor can then call each other and rely on the fact that the vtable is initialized. However, constructor need to do the virtual dispatch as one can call super.
Re: Stroustrup is disappointed with D :(
On Tuesday, 22 September 2015 at 21:25:06 UTC, deadalnix wrote: You can call super, so you need the virtual dispatch. I understand Ali's argument about setting local vtable before calling external functions in C++, but other than that it should be sufficient to set vtable in the new() or equivalent topmost call?
Re: Stroustrup is disappointed with D :(
On Tuesday, 22 September 2015 at 20:42:44 UTC, Ali Çehreli wrote:
However, it is not possible in general e.g. if the object is
passed to a function by reference, that function can call any
virtual method on it so the vtbl pointer must have been set
upon entry to the constructor, at every level of the hierarchy.
Ugh, yes, but using "this" externally on a partially constructed
object is reeelly ugly... If we want to get closer to
something not horribly flawed we would have to do something like:
constructor() {
super();
this.vtable = super::vtable
dostuff( this cast as super)
fully_init_myself()
this.vtable = myself::vtable;
domorestuff(this)
}
What a mess...
BTW, the language Beta had type variables that could be virtual.
It was used for things like the element types for containers. In
that case the super class could instantiate a specialized type
provided by subclasses as a virtual type. Kind of neat, but I
never used it much...
I tried to determine the actual author. It was not easy and I
still don't know. :)
Me neither. I'm getting the impression that I am looking at a
wall of guidelines-graffiti.
Re: Stroustrup is disappointed with D :(
On Tuesday, 22 September 2015 at 19:52:48 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 22 September 2015 at 19:38:35 UTC, Ali Çehreli wrote: C++'s approach is better from the point of view of corretness. However, it is slower because the object's vtbl pointer must be stamped several times during construction. (I am not aware of available compiler optimizations there.) No dispatch needed if calls it's own functions, so no vtable needed for the constructor. But neither approach is good for correctness. You can call super, so you need the virtual dispatch.
Re: Stroustrup is disappointed with D :(
On 9/22/15 12:38 PM, Ali Çehreli via Digitalmars-d wrote: On 09/22/2015 11:58 AM, Tourist wrote: "D disappointed me so much when it went the Java way". https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#to-do-unclassified-proto-rules It's something about virtual calls, but I didn't understand what he means. What does he mean? It is about virtual calls in ctors and dtors. Here is the problem: snip for length Although we are in the middle of consructing a D, the call foo() inside B's ctor is dispatched to D's virtual foo() even though the D part of the object has not been constructed yet. This is in contrast to C++, where the object goes through multiple personalities during its construction: First B, then D, etc. The program above prints derived derived is only now complete As can be seen, D.foo is called before D is ready for use. The output of the C++ program: base derived is only now complete C++'s approach is better from the point of view of correctness. However, it is slower because the object's vtbl pointer must be stamped several times during construction. (I am not aware of available compiler optimizations there.) Ali Keep in mind there's another core difference between c++ and d here and that is: when member variables are set their initial values. In D, it's before any ctors are called for the full object. In c++ they're split into the parts associated with each step in the hierarchy and set as effectively line 0 of the ctor (even though syntactically outside the body of the ctor). These differences are subtle, but can be critical for code that's doing what many would say is too much in the ctor.
Re: Stroustrup is disappointed with D :(
On Tuesday, 22 September 2015 at 19:52:48 UTC, Ola Fosheim Grøstad wrote: But neither approach is good for correctness. The approach that would be "Good for Correctness" is "Hey! You're doing to much work in a constructor, that's a code smell anyway. And invoking virtual methods in a constructor is bound to be flaky no matter what the language designer chooses... so don't do that."
Re: Stroustrup is disappointed with D :(
On 09/22/2015 12:52 PM, Ola Fosheim Grøstad wrote: On Tuesday, 22 September 2015 at 19:38:35 UTC, Ali Çehreli wrote: C++'s approach is better from the point of view of corretness. However, it is slower because the object's vtbl pointer must be stamped several times during construction. (I am not aware of available compiler optimizations there.) No dispatch needed if calls it's own functions, so no vtable needed for the constructor. But neither approach is good for correctness. Agreed. Only if all potential virtual uses of the object inside the ctor can be proven to be to the base's type, then yes, setting the vtbl pointer can be elided. However, it is not possible in general e.g. if the object is passed to a function by reference, that function can call any virtual method on it so the vtbl pointer must have been set upon entry to the constructor, at every level of the hierarchy. (OP: The guidelines have 30 committers or something, I somehow doubt Stroustrup wrote all that...) I tried to determine the actual author. It was not easy and I still don't know. :) Ali
Re: Adapting Tree Structures for Processing with SIMD,Instructions
On Tuesday, 22 September 2015 at 19:45:33 UTC, Iakh wrote: Your solution is platform dependent, isn't it? Platform-dependent in what way? Yes, the intrinsic for PMOVMSKB is obviously x86-only. core.simd XMM enum has commented this opcode //PMOVMSKB = 0x660FD7 __simd is similarly DMD-only. – David
Re: Stroustrup is disappointed with D :(
On Tuesday, 22 September 2015 at 19:38:35 UTC, Ali Çehreli wrote: C++'s approach is better from the point of view of corretness. However, it is slower because the object's vtbl pointer must be stamped several times during construction. (I am not aware of available compiler optimizations there.) No dispatch needed if calls it's own functions, so no vtable needed for the constructor. But neither approach is good for correctness. (OP: The guidelines have 30 committers or something, I somehow doubt Stroustrup wrote all that...)
Re: Adapting Tree Structures for Processing with SIMD,Instructions
On Tuesday, 22 September 2015 at 17:46:32 UTC, David Nadlinger wrote: On Tuesday, 22 September 2015 at 16:36:42 UTC, Iakh wrote: __mm_movemask_epi a cornerstone of the topic currently not implemented/not supported in D :( AFAIK it has irregular result format From ldc.gccbuiltins_x86: int __builtin_ia32_pmovmskb128(byte16); int __builtin_ia32_pmovmskb256(byte32); What am I missing? — David Your solution is platform dependent, isn't it? core.simd XMM enum has commented this opcode //PMOVMSKB = 0x660FD7 https://github.com/D-Programming-Language/druntime/blob/master/src/core/simd.d line 241 PMOVMSKB is opcode of the instruction. And there is no instruction generator for this opcode like this: pure nothrow @nogc @safe void16 __simd(XMM opcode, void16 op1, void16 op2);
Re: Stroustrup is disappointed with D :(
On 09/22/2015 11:58 AM, Tourist wrote:
"D disappointed me so much when it went the Java way".
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#to-do-unclassified-proto-rules
It's something about virtual calls, but I didn't understand what he
means. What does he mean?
It is about virtual calls in ctors and dtors. Here is the problem:
import std.stdio;
class B {
this() {
foo();
}
void foo() {
writeln("base");
}
}
class D : B {
this() {
writeln("derived is only now complete");
}
override void foo() {
writeln("derived");
}
}
void main() {
auto b = new D;
}
Although we are in the middle of consructing a D, the call foo() inside
B's ctor is dispatched to D's virtual foo() even though the D part of
the object has not been constructed yet. This is in contrast to C++,
where the object goes through multiple personalities during its
construction: First B, then D, etc.
The program above prints
derived
derived is only now complete
As can be seen, D.foo is called before D is ready for use.
Here is the equivalent C++ program:
#include
using std::cout;
class B {
public:
B() {
foo();
}
virtual ~B() {}
virtual void foo() {
cout << "base\n";
}
};
class D : public B {
public:
D() {
cout << "derived is only now complete\n";
}
virtual void foo() {
cout << "derived\n";
}
};
int main()
{
D d;
}
The output of the C++ program:
base
derived is only now complete
C++'s approach is better from the point of view of corretness. However,
it is slower because the object's vtbl pointer must be stamped several
times during construction. (I am not aware of available compiler
optimizations there.)
Ali
Re: Stroustrup is disappointed with D :(
Perhaps he meant how in Java, methods are virtual by default, unlike C++ where they are final by default. -- Ziad On Tue, Sep 22, 2015 at 12:15 PM, Freddy via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > On Tuesday, 22 September 2015 at 18:58:31 UTC, Tourist wrote: > >> "D disappointed me so much when it went the Java way". >> >> https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#to-do-unclassified-proto-rules >> >> It's something about virtual calls, but I didn't understand what he >> means. What does he mean? >> > > I doubt he is talking about the whole language. From my skimming it seems > he is talking about how D copies java's classes. >
Re: Stroustrup is disappointed with D :(
On Tuesday, 22 September 2015 at 18:58:31 UTC, Tourist wrote: "D disappointed me so much when it went the Java way". https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#to-do-unclassified-proto-rules It's something about virtual calls, but I didn't understand what he means. What does he mean? I doubt he is talking about the whole language. From my skimming it seems he is talking about how D copies java's classes.
Stroustrup is disappointed with D :(
"D disappointed me so much when it went the Java way". https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#to-do-unclassified-proto-rules It's something about virtual calls, but I didn't understand what he means. What does he mean?
Re: Moving back to .NET
On Tuesday, 22 September 2015 at 18:17:42 UTC, Maxim Fomin wrote: Two examples. I am aware of only one case when Walter and Andrei agreed with community. Well, but the community doesn't agree with itself either ;^) But Walter did add @nogc and changed his view on GC being a total non-issue, so obviously forum discussions have an effect on the decision-making process over time. So, my point is that D except communication channel is pretty much the same as standardized languages with respect to changing language. I think the process changes a lot when you are working with an actual language spec for several years and get experimental implementations in compilers a long time before release. Add also the number of qualified eyeballs looking at proposals... I don't think the C++ designers have made many serious mistakes in the last few iterations (although it could happen again in C++17 ;^). When the spec is the compiler, then you get the unfortunate effect that things that are easy to do go in, and things that are hard to do are rejected. Anyway, some of these things are discussed in Stroustrup's keynote: https://github.com/isocpp/CppCoreGuidelines/blob/master/talks/Stroustrup%20-%20CppCon%202015%20keynote.pdf
Re: Moving back to .NET
On Tuesday, 22 September 2015 at 17:43:59 UTC, Maxim Fomin wrote: On Tuesday, 22 September 2015 at 13:38:33 UTC, Chris wrote: Sure, but in many cases D allows you to work around decisions you don't like. Plus, you can actively contribute, make suggestions and prove your case. The length of some threads shows that Walter, Andrei and others involved in the development take input seriously and answer questions and give the reasons for their decisions. Well, in case of C/C++ there is also rationale for decision, but not in the forum form. But providing rationale is not helpful if there is disagreement. To elaborate. If the issue is comparing chances of changing language in a user-oriented way of D and standardized languages, then it is definitely no. First of all, there is huge information gap between language hackers and users. Secondly, it is hard to beat the 'committee' argumentation even if they are wrong - they are simply to skilled and experienced. Two examples. I am aware of only one case when Walter and Andrei agreed with community. It is epic bugzilla discussion [1] regarding contract programming. It took 60 comments to convince. [1] https://issues.dlang.org/show_bug.cgi?id=6857 The second example is more recent dmd pull discussion regarding template linkage behavior (Walter + Martin vs. Kenji). After long discussion the outcome was that some rare but used feature was dropped for the sake of dmd internals convenience. Walter's argumentation was that the language feature was working by chance, so relying on it is a mistake (to be more precise, the question was whether to write new code to support feature in another context or to drop it and make code cleaner). After new release there were couple issues filed in bugzilla that complained about new behavior, but were closed as invalid (sorry, don't have link, recollect from memory). So, my point is that D except communication channel is pretty much the same as standardized languages with respect to changing language. I would say there are better chances that some feature will suddenly be changed and backfire existing code rather than user will convince to tweak the existing features to make it user - friendly at the expense of internals complexity. I do admit that discussions of new features and simple enhancements provide better chances (discussion is about significant issues, not trivial enhancements - isn't it?).
Re: Adapting Tree Structures for Processing with SIMD,Instructions
On Tuesday, 22 September 2015 at 16:36:42 UTC, Iakh wrote: __mm_movemask_epi a cornerstone of the topic currently not implemented/not supported in D :( AFAIK it has irregular result format From ldc.gccbuiltins_x86: int __builtin_ia32_pmovmskb128(byte16); int __builtin_ia32_pmovmskb256(byte32); What am I missing? — David
Re: Moving back to .NET
On Tuesday, 22 September 2015 at 13:38:33 UTC, Chris wrote: On Tuesday, 22 September 2015 at 11:44:35 UTC, Maxim Fomin wrote: On Tuesday, 22 September 2015 at 11:01:28 UTC, Chris wrote: to be confined by committee decisions etc., D has committee (Walter & Andrei). Some of their decisions frustrate D users too. Sure, but in many cases D allows you to work around decisions you don't like. Plus, you can actively contribute, make suggestions and prove your case. The length of some threads shows that Walter, Andrei and others involved in the development take input seriously and answer questions and give the reasons for their decisions. Well, in case of C/C++ there is also rationale for decision, but not in the forum form. But providing rationale is not helpful if there is disagreement. That these decisions are not always to everyone's liking is inevitable. Given the contradictory nature of requirements in programming, it's only logical that one cannot cater for both sides all the time. Definitely agree.
Re: Moving back to .NET
On Tuesday, 22 September 2015 at 11:01:28 UTC, Chris wrote: The thing is that a lot of people who use D don't mind the lack of IDE support. One reason is that D doesn't need it as badly as e.g. Java or C++. These are bad excuses.
Re: Adapting Tree Structures for Processing with SIMD,Instructions
On Tuesday, 22 September 2015 at 13:06:39 UTC, Andrei Alexandrescu wrote: A paper I found interesting: http://openproceedings.org/EDBT/2014/paper_107.pdf -- Andrei __mm_movemask_epi a cornerstone of the topic currently not implemented/not supported in D :( AFAIK it has irregular result format
Re: Moving back to .NET
On Tuesday, 22 September 2015 at 13:38:33 UTC, Chris wrote: it's only from D that users expect perfection, other languages are accepted as they are, warts and all. it's true
Re: Moving back to .NET
On Tuesday, 22 September 2015 at 15:34:19 UTC, Chris wrote: Then we need a transition strategy. I wouldn't mind refactoring my code in order to adapt it to changes that are for the better in the long run. However, I wouldn't want it to happen in a sudden way that would render all my code useless. Nobody would accept this. I agree, one could have an experimental compiler that accepts a modified subset of current D, yet is capable of linking with existing D code perhaps.
Re: Moving back to .NET
On Tuesday, 22 September 2015 at 14:46:30 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 22 September 2015 at 13:38:33 UTC, Chris wrote: too long. But as I said before, it's only from D that users expect perfection, other languages are accepted as they are, warts and all. I don't think that is true. I do, because every other (new) language is embraced as _the_ way to go, while in the D community even minor issues are blown out of proportion. A problem for D today is that D1 was originally deliberately constrained, which made perfect sense when the language was small (just like it makes sense for Go today). But D2 is deliberately open, yet D2 has added features without redefining the core language from D1 first. It is possible to fix it, by defining a minimal D language and move everything else to libraries, but not without breaking backwards compatibility. Then we need a transition strategy. I wouldn't mind refactoring my code in order to adapt it to changes that are for the better in the long run. However, I wouldn't want it to happen in a sudden way that would render all my code useless. Nobody would accept this.
Re: Moving back to .NET
On Tuesday, 22 September 2015 at 13:38:33 UTC, Chris wrote: too long. But as I said before, it's only from D that users expect perfection, other languages are accepted as they are, warts and all. I don't think that is true. It has been common among C++ users to build custom libraries with very little use of the standard library. C++ has never been accepted with warts and all. It is just C++ was the only option next to C, so people have rolled their own _gradually_ moving from C towards the C++ feature set. Like, I wrote my own array reference library in the spring, but I am now replacing it with a C++17 prototype array_view since an implementation is available from Microsoft now. What has made C and C++ tolerable is that they are very adaptable languages with very few deliberate constraints and runtime requirements. A problem for D today is that D1 was originally deliberately constrained, which made perfect sense when the language was small (just like it makes sense for Go today). But D2 is deliberately open, yet D2 has added features without redefining the core language from D1 first. It is possible to fix it, by defining a minimal D language and move everything else to libraries, but not without breaking backwards compatibility. C/C++ are stuck in the 70s as far as memory goes, but D is still undecided. Leaving the field totally open for Rust who is moving quite fast AFAICT.
Re: Moving back to .NET
On Tuesday, 22 September 2015 at 11:44:35 UTC, Maxim Fomin wrote: On Tuesday, 22 September 2015 at 11:01:28 UTC, Chris wrote: to be confined by committee decisions etc., D has committee (Walter & Andrei). Some of their decisions frustrate D users too. Sure, but in many cases D allows you to work around decisions you don't like. Plus, you can actively contribute, make suggestions and prove your case. The length of some threads shows that Walter, Andrei and others involved in the development take input seriously and answer questions and give the reasons for their decisions. That a language needs people who make the final decision about something is necessary. That these decisions are not always to everyone's liking is inevitable. Given the contradictory nature of requirements in programming, it's only logical that one cannot cater for both sides all the time. D has a long list of requested features that actually made it into the language quite fast, unlike other languages that beat about the bush for years, before they finally incorporate something users really do want. So the general approach is sound, however, due to a lack of resources, not all is well, e.g. PRs stay in the pipe too long. But as I said before, it's only from D that users expect perfection, other languages are accepted as they are, warts and all.
Adapting Tree Structures for Processing with SIMD,Instructions
A paper I found interesting: http://openproceedings.org/EDBT/2014/paper_107.pdf -- Andrei
Re: Moving back to .NET
On Tuesday, 22 September 2015 at 11:01:28 UTC, Chris wrote: to be confined by committee decisions etc., D has committee (Walter & Andrei). Some of their decisions frustrate D users too.
Re: Moving back to .NET
On Sunday, 20 September 2015 at 17:32:53 UTC, Adam wrote: It's almost exclusively due to the error messages and IDE. I know many here will write off such complaints, So be it. The thing is that a lot of people who use D don't mind the lack of IDE support. One reason is that D doesn't need it as badly as e.g. Java or C++. Once you are comfortable with the idea of component programming, there's less need for an IDE. I don't know about .NET, but Java programs consist usually of classes that are somehow interwoven. In D you'd go for independent components that you can later stick together like Lego. I usually write new components as tiny projects with unit tests etc., and plug them into the big project once I'm happy with them. In this way, you don't work on the big project all the time, mostly on small components you add to the big project later. Remember, no reason to have the sharpest sword if you can't wield it. Another reason is that for D programmers the power of D outweighs the lack of IDE support. While you may have an easy life with IDE-languages like Java or C#, the frustration of not being able to do certain things, to be confined by committee decisions etc., is worse in the long run. So D people prefer to learn how to wield the sharpest sword, although it may take some time. It's like everything in life, really, if you take the hard way, you'll get more out of it in the long run. So don't give up. Maybe D will come to the rescue one day, when you hit a brick wall with .NET ;) PS As to error messages, you'll soon know the "usual suspects".
Re: Moving back to .NET
On Tuesday, 22 September 2015 at 06:03:25 UTC, Laeeth Isharc wrote: On Monday, 21 September 2015 at 19:15:28 UTC, Maxim Fomin wrote: OK, the frustration is understandable. D is good enough to impress in short-run but has problems damaging itself in the long run. This leads to impression -> frustration cycle. Well, that may or may not be true. But someone who finds the error messages offputting isn't a good exemplar of putative deficiencies that show up in the long run, because these are part of the initial learning curve and after a year or two or experience it's really unlikely to be a main factor in determining choice of framework. Whereas it's understandable that in the beginning it can be a big source of frustration. I do not consider error messages as long run issue (it is discussed in the thread and I didn't mentioned it, so it might caused impression that I agree with complains about error messages). And if you leave the Microsoft ecosystem, I am not sure that D fares so badly in relation to a certain C family language that has had a big influence. If Microsoft ecosystem is left out then my opinion regarding comparison with Microsoft system is obviously irrelevant. Comparing with other languages I found D is decently good. He didn't say how long he had been using D for, but as others point out one underestimates how much one knows in relation to existing languages, and forgets that it is a degree of work over months and years to learn something new... I always could not understand complaints regarding D hard learning curve for anyone with C/C++/C# background. Either you need portability and you care what Mono does, or you don't. Commercial decisions are often a matter of tradeoffs. Eg for internal enterprise software you might find it valuable to be able to run on both linux and windows, but you can always make it a service on windows if linux is too much trouble. Sounds like 'lazy' portability: if app is portable - than good, if not - ok, we can leave with it:)
Re: Moving back to .NET
On Mon, 21 Sep 2015 19:07:32 +, Adam D. Ruppe wrote: >> https://issues.dlang.org/show_bug.cgi?id=10679 > > I don't think this one is valid though maybe I'm wrong. But the > instruction pointer would be on the next instruction. You are correct and I realized this later on and 'fixed' it in druntime: https://github.com/D-Programming-Language/druntime/ commit/8822115bc8d52fa61c15cef38fe77349f18747b9. I will close this now.
