Opt-in versioning

[Michael Haufe]

The entire concept of {{ ... }} irks me, and probably quite a few 
others. This would add a level of syntax complexity and confusion 
non-intuitive to most developers.

Object literal {{ foo : bar}}?

function(){{...}} ?

if(){{
...
}}
else {{
...
}}

switch()? with()? Imagine JSON with these rules. thats abhorrent. I 
understand the concern with scoping but this would be too far of a shift 
to be considered I would hope.

 >>I would like an arrangement that combines opt-in and explicit
 >>block-type notation.
 >>
 >>A block is either scoping or non-scoping:
 >>
 >>     function Test (List)
 >>     {{
 >>             if (Debugging)
 >>             {
 >>                     const DbName = "Test";
 >>                     var Counter = 5;
 >>             }
 >>
 >>             for (var Num = 0; Num < List.length; ++Num)
 >>             {{
 >>                     var Text = List [Num];
 >>                     Result += Text [3];
 >>             }}
 >>     }}
 >>
 >>Double braces {{ }} indicate a scoping block, single braces
 >>{ } indicate a non-scoping block. A declaration binds the
 >>name to the nearest surrounding scoping block {{ }}. A non-
 >>scoping block { } can never bind a name. All the keywords
 >>var, const, function etc. behave in exactly the same way
 >>in this regard.
 >>
 >>You opt in by using double braces at a point where a block is
 >>possible. At the outermost level of the source text the old
 >>rules apply. If you use { } the old rules remain in force.
 >>If at any point you surround a block with {{ }}, then inside
 >>this block double braces {{ }} are always scoping and single
 >>braces { } are never scoping.
 >>
 >>You can choose freely between scoping and non-scoping block
 >>wherever this is supported by the standard. When a context
 >>requires a certain type of block you must use the correct
 >>markings, else a syntax error is thrown. There is no hidden
 >>automatic correction, your notation must be correct. (But
 >>only when you enable this.) This is so a programmer who
 >>doesn't know the requirement is told. No hidden semantics!
 >>
 >>So if the language requires that all function blocks must
 >>be scoping, then when this is enabled you can only mark
 >>function blocks with {{ }}. And if the language can't
 >>deal with a certain construct written in a non-scoping
 >>block, then you can only put this construct in blocks
 >>that you mark {{ }}.
 >>
 >>If peculiar rules are needed, they won't cause surprises if
 >>they become opt-in together with the syntax change. But I'm
 >>hoping that the above, together with clear compilation error
 >>messages, can minimize peculiarities and make things clear
 >>and simple.
 >>
 >>Note that old browsers can compile source that uses this
 >>syntax. However the meaning may be different. Hopefully
 >>with suitable preparations and restrictions a linter or an
 >>ECMAScript implementation can check the intended meaning
 >>and analyze whether the program will have this intended
 >>meaning when compiled in an old browser.
 >>
 >>One unknown factor is that I don't know if the proposed
 >>markings are sufficient for opt-in, or if something else
 >>is required to avoid incompatible ambiguity.
 >>
 >>The scoping rules of ECMAScript are becoming very complicated.
 >>The behavior of the keyword "function" varies so much among
 >>vendors that it can't be standardized,
 >>https://mail.mozilla.org/pipermail/es3.x-discuss/2008-July/000280.html
 >>"var" and "const" have now been specified to behave each in
 >>its own way, and "let" requires many paragraphs of explanation.
 >>
 >>I think the above can offer simplicity and clarity.
 >>
 >>Ingvar