Boolean shortcuts

Booleans are very nice concept, but can get bulky. That is why people may avoid using it, sometimes. Moreover, booleans are often put inside nice "traity" names like isRetired or done which are nice in constructs like if (!retired) {...}. It would be nice if they could be declared using shorter, more natural way (more descriptive) instead of using explicit true and false value assignment (imperative). Booleans have some instrinsic non-imperative, descriptive feel, so I'd like to be able to express it.

In literals. In literals, let it be possible to use not only foo:true and baz:false productions (comma-terminated except the very last one), but also simplified foo and !baz productions. This will allow for example this nice thing:

Object.defineProperty(foo, "id", {
  value: "Moo",
  !enumerable, configurable, writable
});

By this I have stolen ! character from Allen Wirfs-Brock's use in literal extension (http://wiki.ecmascript.org/doku.php?id=harmony:concise_object_literal_extensions), but I believe ! is associated with boolean not and this use would be more fit for it. Literals created this way (if booleans have "traity" names) are shorter and naturally readable, so if this would be accepted for literals only, it would be nice. Though I can envision the use of this in the rest of boolean-value-assignment contexts, like:

In variable declarations. In variable declaration it would be nice if instead of var done = false; it could be simply put that var !done;. I am not proposing this for general assign (it would be awkward), only for initialization in declaration.

This brings a sad assymetry that I can not use similar streamlined var soFarSoGood; instead of var soFarSoGood = true;. false have its shortcut initalization, and true does not? I do have a workaround proposal for this, though it it less nice, but it is an idiom known to all Javascripters with some experience. Let us allow use var !!soFarSoGood; as well. It can then be used as a shortcut true if developer sees it fit for the situation.

The above paragraphs should of course hold for let and const declarations, as well.

In classes. In classes (that is, in their prototypes, which are outlined by class {...} block) the use of booleans is not very common, but for the sake of orthogonality and not creating special cases (it is a curly block, too, same as object literal and code block), let it be used in public declaration akin to var above. This can allow for example creating Smalltalkish isDuckType constructs like this:

class Animal {
  public !!isAnimal;
  ...
}

class Ape extends Animal {
  ...
}

class Human extends Ape {
  public !isAnimal;
  public !!isPerson;
  ...
}

(not that it is a great use-case, but just to show there is some; I would propose it even if I knew of none, not to create differences between {...} constructs.)

Herby

EDIT: As pointed out by François Remy:

Doesn't play nice with already existing blocks:
  eval("{ !window }") // returns false;

The (free) code-block is a problematic feature that blocks empowering data {...} since the parser can treat it as code block and in some cases it is hard to tell the two apart.

EDIT2: It does not matter, I was freaked out. This proposal is for the object initializer context. The fact that there is ambiguity if a statement begins with { and parentheses should be used if you want it to process it as an expression statement is fine (like ({}).foo;).