A few simple syntactic proposals

[Sean Kelly]

== Quote from Robert Fraser (fraserofthenight at gmail.com)'s article
> Okay, I read the "handling constructive criticism" topic and Walter's
> reply where he suggests that proposals should go into bugzilla. Based on
> that, I want to start a topic on _MINOR_ changes to the syntax and
> semantics of D that most people should agree upon. If there's any
> objection to these at all, it probably warrants more discussion before
> going into bugzilla, but otherwise these should be added as bugs.
> All of these proposals apply to D2 only. D1 needs to remain as stable as
> possible, IMO, though a few of these might be candidates for backporting.
> I'll start us off with 3 off the top of my head:
> 1. Remove "delete aa[key]" as a syntactic equivalent to "aa.delete(key)"
> for associative arrays. It's been deprecated in both branches of D but
> needs to go from D2, since it goes against the D philosophy of
> unambiguous parsing without semantic analysis.
> 2. Allow interfaces that are not sub-interfaces of IUnknown to be
> explicitly "delete"d.
> 3. String literals should be typed as dynamic arrays. This would mean
> that "foo" would be of type invariant(char)[] not type
> invariant(char)[3u] . Note that this would have the disadvantage of
> requiring an explicit cast if the string literal were to be needed as a
> static array, but how many times have you actually used a string literal
> to initialize a static array (or used a static array at all...?)
> Anyone has the right to veto any proposal here, but if there aren't any
> vetos I may add them to bugzilla.

I'm not sure it's sufficiently simple, but a while back I suggested making
constructors inherited by default.  Here's the link:

http://www.digitalmars.com/d/archives/digitalmars/D/Inheriting_constructors_54088.html

For simple stuff, I'd like to see opEquals return a bool if it doesn't already
in D 2.0.  Also, I'd like closures to be given some attention.  Currently, they
seem to allocate too often for non-escaping closures.  This needs to be
looked at and if syntax must be added to override the automatic allocation
then it should be done sooner than later.


Sean