www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Stack overflow

reply "Namespace" <rswhite4 googlemail.com> writes:
I have this code:
http://codepad.org/vz17iZrm

And as long as i comment out the assert's in the constructor on 
line 10 and the assert in the invariant on line 16 it works as i 
want.
But otherwise the compiler prints stackoverflow and that's all.

Why and how is the stack overflowed with an simple assert?!
Jun 22 2012
next sibling parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 22-06-2012 12:22, Namespace wrote:
 I have this code:
 http://codepad.org/vz17iZrm

 And as long as i comment out the assert's in the constructor on line 10
 and the assert in the invariant on line 16 it works as i want.
 But otherwise the compiler prints stackoverflow and that's all.

 Why and how is the stack overflowed with an simple assert?!

Wow, you really managed to dig up some compiler bugs here. OK, so first of all, if you change the asserts to assert(obj); and assert(_obj); (I assume this is what you meant in the invariant), the code compiles. This is clearly a bug. Now, if you change the first assert to assert(obj); and the one in the invariant to assert(obj); *too* (invalid code), the compiler just plain seg faults. The workaround, as mentioned, is to either use assert(obj); and assert(_obj); or assert(!!obj); and assert(!!_obj);. The reason the latter forms may be desirable is that the former calls obj's invariant in addition to checking for null. The latter doesn't. In any case, please file bugs for these issues. You really managed to run into some unusually broken parts of the compiler, it seems. :-/ -- Alex Rønne Petersen alex lycus.org http://lycus.org
Jun 22 2012
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06/22/2012 12:22 PM, Namespace wrote:
 I have this code:
 http://codepad.org/vz17iZrm

 And as long as i comment out the assert's in the constructor on line 10
 and the assert in the invariant on line 16 it works as i want.
 But otherwise the compiler prints stackoverflow and that's all.

 Why and how is the stack overflowed with an simple assert?!

On my machine it is the compiler that crashes => compiler bug. Presumably it is having trouble with the circular alias this. (BTW, what is 'obj' in the invariant supposed to refer to?)
Jun 22 2012
parent reply David <d dav1d.de> writes:
Am 22.06.2012 12:52, schrieb Namespace:
 On my machine it is the compiler that crashes => compiler bug.
 Presumably it is having trouble with the circular alias this.

My first try to avoid this "circular" bug work with opDispatch. (As you can read here on my blog: http://blog.rswhite.de/archives/741) Now i had a new idea to save the Reference and call only these, it seems that it works fine and with a lot less code.
 (BTW, what is 'obj' in the invariant supposed to refer to?)

Alex Rønne Petersen: Thanks a lot, i use assert(obj); that seems to serve the purpose. I hope in the next version "alias this" is more stable.

a contract which checks for null and you're done (another benefit, it get's removed if you compile with -release). The only thing you gain from that is an Exception instead of a Segfault, where is the benefit, the app crashes in both cases and if you wanna handle those Exceptions, you can also check for null which is definitly faster and more readable (because it's clear to everyone). There were a few discussion about adding a NullPointerException, personally I wouldn't care if there was one, but implementing this behaviour with a library is the wrong way imo. This spreads inconsistency over D, some use it others don't, beginners will be confused. Btw. when developing, just start your program always with a debugger (shift+F9 instead of F9 for me, not a big deal), it will halt on a segfault and you can check why there is one.
Jun 22 2012
parent reply David <d dav1d.de> writes:
Am 22.06.2012 16:55, schrieb Namespace:
 If you have a null object you get an Access Violation without _any_
 further information. That totally sucks.

I don't know what you're doing or which debugger you use, gdb shows me exactly what happened (line + stack + object).
 And in my opinion a small "Ref!Type" is more informative for others who
 use your code and you do not have to write assert(obj !is null); any
 time in any method again.

I hope nobody will share code with Ref!Type, if they do people will relay on it and hey, all will do it, I don't need to check here, would be something different if it was not implemented by any library.
 And yes my program start's first with a debugger but, as i said, you
 will only get "Access Violation" and must debug by yourself to find the
 null object, if you avoid assert's.

I have to debug nothing, as written above gdb sets automatically a breakpoint on a segmentation fault and shows me all the information I need.
Jun 22 2012
parent reply David <d dav1d.de> writes:
Am 22.06.2012 23:11, schrieb Namespace:
 debugger), but my guess is that Namespace just doesn't know how to do
 that or
 that it's even possible - hence his frustration with not getting any
 information.

Exactly. And I use VisualD and the standard debugger of it.

Sorry but I would learn how to use the debugger instead (it helps a lot!), instead of implementing features which emulate C++ behaviour (according to your blog) and will confuse people, e.g. if you documentate that, people will be like *huh this cannot be null, is this a feature I don't know?* and end up confused.
Jun 22 2012
next sibling parent David <d dav1d.de> writes:
Am 23.06.2012 07:27, schrieb Namespace:
 I would prefer NullPointer Exceptions and / or not null types rather
 than playing around with the debugger.
 That's the first step.

Yeah but not implemented by a library.
Jun 23 2012
prev sibling parent reply David <d dav1d.de> writes:
Am 24.06.2012 11:35, schrieb Namespace:
 A non-nullable type _will_ be added to Phobos at some point.

As struct or class or as built-in type? And can me explain somebody why [code] disable this(typeof(null)); [/code] print "Stack overflow"?

What should typeof(null) return you? void*, int*
Jun 24 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06/24/2012 12:37 PM, David wrote:
 Am 24.06.2012 11:35, schrieb Namespace:
 A non-nullable type _will_ be added to Phobos at some point.

As struct or class or as built-in type? And can me explain somebody why [code] disable this(typeof(null)); [/code] print "Stack overflow"?

What should typeof(null) return you? void*, int*

typeof(null) gives typeof(null).
Jun 24 2012
parent David <d dav1d.de> writes:
Am 24.06.2012 13:15, schrieb Timon Gehr:
 On 06/24/2012 12:37 PM, David wrote:
 Am 24.06.2012 11:35, schrieb Namespace:
 A non-nullable type _will_ be added to Phobos at some point.

As struct or class or as built-in type? And can me explain somebody why [code] disable this(typeof(null)); [/code] print "Stack overflow"?

What should typeof(null) return you? void*, int*

typeof(null) gives typeof(null).

Right my bad, I was confused a bit
Jun 24 2012
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
 On my machine it is the compiler that crashes => compiler bug.
 Presumably it is having trouble with the circular alias this.

My first try to avoid this "circular" bug work with opDispatch. (As you can read here on my blog: http://blog.rswhite.de/archives/741) Now i had a new idea to save the Reference and call only these, it seems that it works fine and with a lot less code.
 (BTW, what is 'obj' in the invariant supposed to refer to?)

Alex Rønne Petersen: Thanks a lot, i use assert(obj); that seems to serve the purpose. I hope in the next version "alias this" is more stable.
Jun 22 2012
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
If you have a null object you get an Access Violation without 
_any_ further information. That totally sucks.
And in my opinion a small "Ref!Type" is more informative for 
others who use your code and you do not have to write assert(obj 
!is null); any time in any method again.

And yes my program start's first with a debugger but, as i said, 
you will only get "Access Violation" and must debug by yourself 
to find the null object, if you avoid assert's.
Jun 22 2012
prev sibling next sibling parent "Regan Heath" <regan netmail.co.nz> writes:
On Fri, 22 Jun 2012 15:55:12 +0100, Namespace <rswhite4 googlemail.com>  
wrote:

 If you have a null object you get an Access Violation without _any_  
 further information. That totally sucks.

It doesn't have to be that way. A debug executable contains all sort of debugging information and a Just In Time debugger can attach and make use of it to show the cause of the access violation. Further, on both windows and various flavours of unix you can get a stack dump, which can be loaded into a debugger and used to locate the access violation. For the JIT case it's all automated on windows if/when you have visual studio installed, as soon as any application crashes a dialog appears and you can attach/debug. For the stack trace case I prefer using WinDbg where you can load the stack trace, point it at the PDB (produced even on a release build) and figure out where it crashed. If you have no PDB you can use a MAP file and the stack offsets to determine the crash location. Alternately, on windows you can call SetUnhandledExceptionFilter() to install a handler to catch any/all unhandled "exceptions" including access violations etc and then using the EXCEPTION_POINTERS ContextRecord member, walk the stack and produce your own stack trace at the instant the application "crashes" - I have some code which does this somewhere.. This last idea could automatically be built into exes produced by DMD so they all crash and output a stack trace (perhaps only if built in debug mode) and something similar can surely be done for unix. It's been a while since I did any serious development in D so maybe automatic stack traces already happen for some platforms?
 And in my opinion a small "Ref!Type" is more informative for others who  
 use your code and you do not have to write assert(obj !is null); any  
 time in any method again.

It is nice to perform the assert/check once, then know from that point on it cannot be null ever again - saves multiple asserts/checks and makes the code cleaner in terms of having less "noise". I think types which cannot be null are useful for that reason. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Jun 22 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, June 22, 2012 19:59:48 David wrote:
 Am 22.06.2012 16:55, schrieb Namespace:
 If you have a null object you get an Access Violation without _any_
 further information. That totally sucks.

I don't know what you're doing or which debugger you use, gdb shows me exactly what happened (line + stack + object).

Well, he's clearly on Windows if he's seeing an access violation, but regardless, there are plenty of developers who have no clue that you can get any information from a segfault or access violation. Personally, I'd been programming in C/C++ for years before I found out it was possible. And it can be _very_ frustrating to get a segfault when all that tells you is that you're programming is crashing somewhere, somehow. Fortunately, debuggers like gdb make it possible to figure out what happened in great detail (either by examining a core dump or running the program in a debugger), but my guess is that Namespace just doesn't know how to do that or that it's even possible - hence his frustration with not getting any information. - Jonathan M Davis
Jun 22 2012
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
 debugger), but my guess is that Namespace just doesn't know how 
 to do that or
 that it's even possible - hence his frustration with not 
 getting any
 information.

Exactly. And I use VisualD and the standard debugger of it.
Jun 22 2012
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
On Friday, 22 June 2012 at 23:01:47 UTC, David wrote:
 Am 22.06.2012 23:11, schrieb Namespace:
 debugger), but my guess is that Namespace just doesn't know 
 how to do
 that or
 that it's even possible - hence his frustration with not 
 getting any
 information.

Exactly. And I use VisualD and the standard debugger of it.

Sorry but I would learn how to use the debugger instead (it helps a lot!), instead of implementing features which emulate C++ behaviour (according to your blog) and will confuse people, e.g. if you documentate that, people will be like *huh this cannot be null, is this a feature I don't know?* and end up confused.

I would prefer NullPointer Exceptions and / or not null types rather than playing around with the debugger. That's the first step.
Jun 22 2012
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
On Saturday, 23 June 2012 at 09:53:35 UTC, David wrote:
 Am 23.06.2012 07:27, schrieb Namespace:
 I would prefer NullPointer Exceptions and / or not null types 
 rather
 than playing around with the debugger.
 That's the first step.

Yeah but not implemented by a library.

Not yet. ;)
Jun 23 2012
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
So here i proudly present my Ref struct (2.0 ;))
http://dpaste.dzfl.pl/905e1d3d

So, any suggestions, further ideas or criticism?
Jun 23 2012
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
BTW: Any tries to declare
 disable
this(typeof(null)); end with the same message "Stack overflow"...
Jun 23 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, June 23, 2012 07:27:56 Namespace wrote:
 I would prefer NullPointer Exceptions and / or not null types
 rather than playing around with the debugger.
 That's the first step.

NullPointerExceptions (well, they'd end up being NullPointersErrors) will _never_ happen. Walter is completely against them. From his point of view, the OS is _already_ checking this for you (hence the segfault or access violation), so there's no point in having the language check. We might end up with something in druntime which prints out a stacktrace when a segfault occurs, but that's the closest that you'll ever get to a null pointer exception in D. A non-nullable type _will_ be added to Phobos at some point. The issue is a matter of implementation. At least one has been submitted, but it wasn't good enough to be included as it stood. So, it hasn't been merged in. As soon as there is one which is good enough and has been appropriately reviewed by the Phobos devs, we'll have one. But until then, we don't. - Jonathan M Davis
Jun 23 2012
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
 A non-nullable type _will_ be added to Phobos at some point.

As struct or class or as built-in type? And can me explain somebody why [code] disable this(typeof(null)); [/code] print "Stack overflow"?
Jun 24 2012
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
On Sunday, 24 June 2012 at 10:37:39 UTC, David wrote:
 Am 24.06.2012 11:35, schrieb Namespace:
 A non-nullable type _will_ be added to Phobos at some point.

As struct or class or as built-in type? And can me explain somebody why [code] disable this(typeof(null)); [/code] print "Stack overflow"?

What should typeof(null) return you? void*, int*

I don't understand, what do you mean?
Jun 24 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, June 24, 2012 11:35:46 Namespace wrote:
 A non-nullable type _will_ be added to Phobos at some point.

As struct or class or as built-in type?

As I said, it will be added to _Phobos_. So, it will be a struct in the standard library, not in the language itself. It'll probably be NonNullable!T. - Jonathan M Davis
Jun 24 2012
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
On Sunday, 24 June 2012 at 11:55:15 UTC, Jonathan M Davis wrote:
 On Sunday, June 24, 2012 11:35:46 Namespace wrote:
 A non-nullable type _will_ be added to Phobos at some point.

As struct or class or as built-in type?

As I said, it will be added to _Phobos_. So, it will be a struct in the standard library, not in the language itself. It'll probably be NonNullable!T. - Jonathan M Davis

You can take my Ref struct. ;) And can me now anybody explain why disable this(typeof(null)); or any other ctor declaration prints "stack overflow"? How it is possible, that one class and one struct kill the stack?
Jun 24 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, June 24, 2012 14:09:38 Namespace wrote:
 And can me now anybody explain why
  disable
 this(typeof(null)); or any other ctor declaration prints "stack
 overflow"?
 How it is possible, that one class and one struct kill the stack?

Please provide a compilable example which exhibits the problem so that we can see exactly what you're talking about and reproduce it. - Jonathan M Davis
Jun 24 2012
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
On Sunday, 24 June 2012 at 12:19:47 UTC, Jonathan M Davis wrote:
 On Sunday, June 24, 2012 14:09:38 Namespace wrote:
 And can me now anybody explain why
  disable
 this(typeof(null)); or any other ctor declaration prints "stack
 overflow"?
 How it is possible, that one class and one struct kill the 
 stack?

Please provide a compilable example which exhibits the problem so that we can see exactly what you're talking about and reproduce it. - Jonathan M Davis

http://dpaste.dzfl.pl/ca77bc96 Comment out "alias this" in Foo or " disable this(typeof(null));" in Test solve the problem. Otherwise it prints "Stack overflow".
Jun 24 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, June 24, 2012 14:29:10 Namespace wrote:
 On Sunday, 24 June 2012 at 12:19:47 UTC, Jonathan M Davis wrote:
 On Sunday, June 24, 2012 14:09:38 Namespace wrote:
 And can me now anybody explain why
  disable
 this(typeof(null)); or any other ctor declaration prints "stack
 overflow"?
 How it is possible, that one class and one struct kill the
 stack?

Please provide a compilable example which exhibits the problem so that we can see exactly what you're talking about and reproduce it. - Jonathan M Davis

http://dpaste.dzfl.pl/ca77bc96 Comment out "alias this" in Foo or " disable this(typeof(null));" in Test solve the problem. Otherwise it prints "Stack overflow".

My guess is that you've got something recursive going on (possibly a recursive template instantiation, though I don't see any reason why that would occur), which causes it to eat up more and more memory, until the OS kills it. Report it as a dmd bug: http://d.puremagic.com - Jonathan M Davis
Jun 24 2012
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
 My guess is that you've got something recursive going on 
 (possibly a recursive
 template instantiation, though I don't see any reason why that 
 would occur),
 which causes it to eat up more and more memory, until the OS 
 kills it.

 Report it as a dmd bug: http://d.puremagic.com

 - Jonathan M Davis

All right, but have you any workaround? As long as it endures to fix a bug in dmd, i'm a old men when i can work with it.
Jun 24 2012
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, June 24, 2012 14:57:37 Namespace wrote:
 My guess is that you've got something recursive going on
 (possibly a recursive
 template instantiation, though I don't see any reason why that
 would occur),
 which causes it to eat up more and more memory, until the OS
 kills it.
 
 Report it as a dmd bug: http://d.puremagic.com
 
 - Jonathan M Davis

All right, but have you any workaround? As long as it endures to fix a bug in dmd, i'm a old men when i can work with it.

This might work: this(U)(U obj) if(is(U : T) && !is(U == typeof(null))) { } - Jonathan M Davis
Jun 24 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06/25/2012 02:48 AM, Jonathan M Davis wrote:
 On Sunday, June 24, 2012 19:03:17 Namespace wrote:
 This might work:

 this(U)(U obj)

      if(is(U : T)&&  !is(U == typeof(null)))

 {
 }


 - Jonathan M Davis

Interesting. With or wihtout that, if i add a method to Foo it prints "Stack overflow" also. http://dpaste.dzfl.pl/91dad66c Can you explain that?

Wait, you have a template mixin inside of Foo which passes Foo to it? I don't know if you can get away with that or not, since you're trying to pass a type to a template while you're adding stuff to it via that template. So, the type is incomplete. I'm willing to be that that's your problem, but I don't know. - Jonathan M Davis

This is fine. I am doing it all the time. Why are we discussing this compiler bug on the main newsgroup though?
Jun 25 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06/25/2012 02:18 PM, Namespace wrote:
 Fine. But nothing of them explain the Stack overflow if i add an
 additional method or disable/add an additional ctor.

It does not have to be explained: it is a compiler bug.
Jun 25 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 06/25/2012 05:52 PM, Namespace wrote:
 On Monday, 25 June 2012 at 15:39:19 UTC, Timon Gehr wrote:
 On 06/25/2012 02:18 PM, Namespace wrote:
 Fine. But nothing of them explain the Stack overflow if i add an
 additional method or disable/add an additional ctor.

It does not have to be explained: it is a compiler bug.

Then it will take months or years until it is fixed ... too bad.

Many of them get fixed quite fast if they are reported properly.
 And that Ref!(Foo) rf = new Foo(); ends even with "Stack overflow" and
 Ref!(Foo) rf2 = new Ref!(Foo)(new Foo()); not has the same explanation
 "Compiler Bug", hm?

It is always a compiler bug if compilation crashes.
Jun 25 2012
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
 This might work:

 this(U)(U obj)
     if(is(U : T) && !is(U == typeof(null)))
 {
 }


 - Jonathan M Davis

Interesting. With or wihtout that, if i add a method to Foo it prints "Stack overflow" also. http://dpaste.dzfl.pl/91dad66c Can you explain that?
Jun 24 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, June 24, 2012 19:03:17 Namespace wrote:
 This might work:
 
 this(U)(U obj)
 
     if(is(U : T) && !is(U == typeof(null)))
 
 {
 }
 
 
 - Jonathan M Davis

Interesting. With or wihtout that, if i add a method to Foo it prints "Stack overflow" also. http://dpaste.dzfl.pl/91dad66c Can you explain that?

Wait, you have a template mixin inside of Foo which passes Foo to it? I don't know if you can get away with that or not, since you're trying to pass a type to a template while you're adding stuff to it via that template. So, the type is incomplete. I'm willing to be that that's your problem, but I don't know. - Jonathan M Davis
Jun 24 2012
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
 Wait, you have a template mixin inside of Foo which passes Foo 
 to it? I don't
 know if you can get away with that or not, since you're trying 
 to pass a type
 to a template while you're adding stuff to it via that 
 template. So, the type
 is incomplete. I'm willing to be that that's your problem, but 
 I don't know.

 - Jonathan M Davis

If so, the problem would have to solved if i switch from a mixin to an abstract class. Or not? Or have you any other idea?
Jun 24 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, June 25, 2012 08:24:59 Namespace wrote:
 Wait, you have a template mixin inside of Foo which passes Foo
 to it? I don't
 know if you can get away with that or not, since you're trying
 to pass a type
 to a template while you're adding stuff to it via that
 template. So, the type
 is incomplete. I'm willing to be that that's your problem, but
 I don't know.
 
 - Jonathan M Davis

If so, the problem would have to solved if i switch from a mixin to an abstract class. Or not? Or have you any other idea?

If you don't need to use any compile-time reflection on the type itself (i.e. you just need its name), you can use a string mixin. - Jonathan M Davis
Jun 25 2012
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
 If you don't need to use any compile-time reflection on the 
 type itself (i.e.
 you just need its name), you can use a string mixin.

 - Jonathan M Davis

You mean i should pack the whole mixin template in a string? Isn't that a little bit ugly?
Jun 25 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, June 25, 2012 10:18:19 Namespace wrote:
 If you don't need to use any compile-time reflection on the
 type itself (i.e.
 you just need its name), you can use a string mixin.
 
 - Jonathan M Davis

You mean i should pack the whole mixin template in a string? Isn't that a little bit ugly?

More or less yeah. You generate the code as a string and then mix it in. As it's a string, it's really easy to manipulate, and if you lay out the strings properly, it's not really even particularly hard to read. Personally, I never use template mixins, and I get the impression that string mixins get used a lot more than template mixins do. - Jonathan M Davis
Jun 25 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, June 25, 2012 13:01:47 Timon Gehr wrote:
 On 06/25/2012 02:48 AM, Jonathan M Davis wrote:
 On Sunday, June 24, 2012 19:03:17 Namespace wrote:
 This might work:
 
 this(U)(U obj)
 
      if(is(U : T)&&  !is(U == typeof(null)))
 
 {
 }
 
 
 - Jonathan M Davis

Interesting. With or wihtout that, if i add a method to Foo it prints "Stack overflow" also. http://dpaste.dzfl.pl/91dad66c Can you explain that?

Wait, you have a template mixin inside of Foo which passes Foo to it? I don't know if you can get away with that or not, since you're trying to pass a type to a template while you're adding stuff to it via that template. So, the type is incomplete. I'm willing to be that that's your problem, but I don't know. - Jonathan M Davis

This is fine. I am doing it all the time.

If it works, then it works, but it surprises me a bit, given that you can't do that with template declarations normally.
 Why are we discussing this compiler bug on the main newsgroup though?

We're not discussing this on the main newsgroup. This is d-learn. - Jonathan M Davis
Jun 25 2012
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
Fine. But nothing of them explain the Stack overflow if i add an 
additional method or disable/add an additional ctor.
Jun 25 2012
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
On Monday, 25 June 2012 at 15:39:19 UTC, Timon Gehr wrote:
 On 06/25/2012 02:18 PM, Namespace wrote:
 Fine. But nothing of them explain the Stack overflow if i add 
 an
 additional method or disable/add an additional ctor.

It does not have to be explained: it is a compiler bug.

Then it will take months or years until it is fixed ... too bad. And that Ref!(Foo) rf = new Foo(); ends even with "Stack overflow" and Ref!(Foo) rf2 = new Ref!(Foo)(new Foo()); not has the same explanation "Compiler Bug", hm?
Jun 25 2012
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
 Many of them get fixed quite fast if they are reported properly.

But since I have had other experiences. But no matter.
 It is always a compiler bug if compilation crashes.

Only that a simple " disable this(typeof(null));" fails, is crap. Because so you cannot test at compile time for such assignments.
Jun 25 2012
prev sibling parent "Namespace" <rswhite4 googlemail.com> writes:
My fault, Ref!(Foo) rf = new Foo(); work as expected.
Jun 25 2012