<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<br>
<br>
<blockquote type="cite" cite="mid:CANSoFxsVJCEXy7O_-099BtDMkBiemPHZ8enpXh04-G02YKwSPg@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div><font size="4"><font face="monospace"><font size="4"><font face="monospace">This brings the spec footprint
down considerably, while still eliminating
complex/risky workarounds around "super first". <br>
</font></font></font></font></div>
</blockquote>
<div><br>
</div>
</div>
Put another way, if a reasonable language change is such a
problem for the spec, then that's a problem to solve with the
spec, not the language.</div>
</blockquote>
<br>
Not sure what you mean; the spec is the language, and the language
is the spec. Many things that seem simple when describing them in
terms of "use DA/DU to ..." or "use inference to ..." turn out to be
complicated to specify -- which means the language changes are more
complicated than they first seemed. Gauging the spec impact is how
we keep ourselves honest about the scope of language changes. <br>
<br>
<blockquote type="cite" cite="mid:CANSoFxsVJCEXy7O_-099BtDMkBiemPHZ8enpXh04-G02YKwSPg@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">Now I'm not a spec expert (it seems
kind of analogous to being a patent lawyer) but what about
this plan:</div>
</div>
</blockquote>
<br>
This is obviously doable, but my recent comments (having looked at
what the spec impact would be) is saying that this is a more
complicated, more invasive language feature than the simpler
"statements before super" feature. Part of what I'm trying to do
here is steer towards success by pruning the problem to one that can
be achieved without spending years immersing yourself in
specification. <br>
<br>
<br>
</body>
</html>