default constructors and implicit super() insertion

Brendan Eich brendan at
Tue Jun 26 18:58:01 PDT 2007

On Jun 26, 2007, at 6:32 PM, Graydon Hoare wrote:

> The committee's feeling was that definite-assignment analysis -- what
> you're describing -- is too expensive, especially for lightweight
> compilers. It might be that any lightweight compiler is actually going
> to run in standard mode all the time anyways, and we might not make
> standard mode obliged to detect failure-to-initialize-non-nullable  
> until
> ctor execution time, in which case there's no "analysis", just a  
> runtime
> bit. I do not have deep feelings either way, and I'm not sure  
> whether we
> decided to support settings lists before or after our notions of  
> strict
> and standard modes had fully formed.

The bias was against definite assignment analysis being required for  
strict mode, never mind good old standard mode, which can as Graydon  
notes detect uninitialized non-nullable properties the hard way at  
runtime, but before the ctor returns an instance whose properties  
must be well initialized.

Perhaps for strict mode we could require DA analysis. If so, we could  
get rid of settings as special syntax. But settings relieve a cost  
not only to implementors -- they also (idiomatic and possibly hated  
syntax aside) require users of non-nullable types to put  
initialization front and center, not possibly obscured or missed in  
the ctor's body's control flow.

> Anyone want to chime in? I suspect a couple of the people with  
> opinions
> are presently or shortly on vacation...

Indeed. We'll hear back in a few weeks, if not sooner, from some  
group members now on vacation.

>> BTW does anyone have any thoughts on my original questions?
> Automatic inference of the default ctor signature and default super- 
> call
> from the superclass would be fine by me. I'm not sure what other  
> people
> think. It'd break AS code.

Peter, could you remind me how super and subclass ctor parameter  
lists would be related? There's no necessary relation. How would this  
work, other than as a convention supported by default, requiring  
overriding to avoid type or argument number errors?


More information about the Es4-discuss mailing list