516 – Mutually calling constructors allowed

D issues are now tracked on GitHub. This Bugzilla instance remains as a read-only archive.
Issue 516 - Mutually calling constructors allowed
Summary: Mutually calling constructors allowed
Status: RESOLVED FIXED
Alias: None
Product: D
Classification: Unclassified
Component: dmd (show other issues)
Version: D1 (retired)
Hardware: x86 Windows
: P4 normal
Assignee: Walter Bright
URL: http://www.digitalmars.com/d/class.html
Keywords: accepts-invalid, spec
Depends on:
Blocks: 511
Show dependency tree / graph
Reported: 2006年11月15日 07:10 UTC by Matti Niemenmaa
Modified: 2014年02月15日 13:20 UTC (History)
1 user (show)

See Also:


Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description Matti Niemenmaa 2006年11月15日 07:10:45 UTC
The spec states under "Constructors" that "It is illegal for constructors to mutually call each other", providing a code snippet similar to the following as a showcase:
class Foo {
	this() { this(1); }
	this(int i) { this(); } // illegal, cyclic constructor calls
}
void main() {
	Foo foo = new Foo();
}
Yet, this code compiles fine, failing at runtime due to a stack overflow.
If the compiler is not meant to detect this, the restriction seems redundant - such calls will obviously fail at runtime just as though the constructors were normal functions, which do not suffer from such a restriction. If the compiler should, however, detect this, then it is a bug that it currently does not.
Comment 1 Walter Bright 2008年06月27日 20:12:21 UTC
There is no way, in the general case, for the compiler to detect this.
Comment 2 Ary Borenszweig 2008年06月27日 20:33:17 UTC
Why not? Java does it. And "this" is bound at static time, not and runtime, and at static time you have all the information needed to detect cycles.
Comment 3 Walter Bright 2008年06月27日 21:58:58 UTC
Because this may be declared as:
 this();
meaning it's body appears elsewhere. Also, things that appear to be cycles in static analysis may not be at runtime, like recursive functions.
Comment 4 Matti Niemenmaa 2008年06月28日 03:52:09 UTC
If it's not possible just remove it from the spec. Why was it there in the first place?
Comment 5 Walter Bright 2008年06月28日 04:52:47 UTC
1. Java doesn't allow separate compilation of constructors.
2. Java doesn't allow any flow control before other constructors are called.
Comment 6 BCS 2008年06月29日 16:46:59 UTC
(In reply to comment #4)
> If it's not possible just remove it from the spec. Why was it there in the
> first place?
> 
Some parts of the spec can be read as "The language is not required to work correctly if you do ____. If you do and "things" happen, it's your error."
Comment 7 Stewart Gordon 2008年06月29日 17:04:17 UTC
Therein lies half the problem. The spec should make a clear distinction between things that are actually illegal, things that cause undefined behaviour and things that the compiler may decide are errors if it's clever enough.
Moreover, I'd read "mutually calling" as meaning that a loop exists in which constructors call which others, regardless of whether the calls can actually loop at runtime.
Comment 8 BCS 2008年06月29日 17:21:55 UTC
I disagree. I think it is valid to say that something is both illegal and that it result in undefined behavior. I think that somewhere it is said, for example, that it is /illegal/ to have code depend on order of evaluation (this can't be checked, the halting problem can be found in there).
Maybe the distinction should be made between things that are illegal and the compiler is required to reject and things that are still illegal but that it needn't detect.


AltStyle によって変換されたページ (->オリジナル) /