removal of cruft from D

[Justin Johansson]

Nick Sabalausky wrote:
> "Yigal Chripun" <yigal100 at gmail.com> wrote in message 
> news:he6sqe$1dqu$1 at digitalmars.com...
>> Based on recent discussions on the NG a few features were 
>> deprecated/removed from D, such as typedef and C style struct 
>> initializers.
>>
>> IMO this cleanup and polish is important and all successful languages do 
>> such cleanup for major releases (Python and Ruby come to mind). I'm glad 
>> to see that D follows in those footsteps instead of accumulating craft 
>> like C++ does.
>>
>>
>> As part of this trend of cleaning up D before the release of D2, what 
>> other features/craft should be removed/deprecated?
>>
>> I suggest reverse_foreach and c style function pointers
>>
>> please add your candidates for removal.
>>
> 
> s/reverse_foreach/foreach_reverse/ ;)
> 
> 1. Floating point literals without digits on *both* sides!!! "1.", ".1" --> 
> Useless hindrance to future language expansion!
> 
> 2. Octal literals! I think it'd be great to have a new octal syntax, or even 
> better, a general any-positive-inter-base syntax. But until that finally 
> happens, I don't want "010 == 8" preserved. And I don't think the ability to 
> have an octal literal is important enough that lacking it for a while is a 
> problem. And if porting-from-C really has to be an issue, then just make 
> 0[0-9_]+ an error for a transitionary period (or forever - it'd at least be 
> better than maintaining "010 == 8").
> 
> 3. Also the comma operator, but that's already been recently discussed.

On 1.  I understand you mean floating point literals without digits on 
both sides of the decimal point should be disallowed.  On basis of this 
understanding I beg to differ on grounds that this *should* be allowed 
for future language expansion.

Rationale: Whilst D is not currently XML aware (to any meaningful level 
of standards compliance), the language may go that way in the future. 
Therefore I would suggest that the lexical form of all literals in the 
language should be aligned with, or at least include the lexical forms 
of, literals as allowed by XML Schema Part 2: Datatypes Second Edition

http://www.w3.org/TR/xmlschema-2/

Specifically this does allow digits to be omitted from either size as 
per the following lexical production:

DoubleLiteral ::=
(("." Digits) | (Digits ("." [0-9]*)?)) [eE] [+-]? Digits

It is noted, of course, that D does provide the very programmer-friendly 
mechanism of allowing underscores to used to separate digits in integer 
literals.  Whilst integers with embedded underscores are not included in 
the lexical space of integers as in cited XML Schema Datatypes, I do not 
argue against them.  In other words, whatever D supports with respect to 
the lexical forms of literals is fine so long as it *does not* preclude 
    lexical forms from XML Schema Datatypes.

On 3.  I cannot see the comma operator being removed in any short space 
of time; this would have the adverse effect of introducing more problems 
  at this stage and would likely delay D2 even further.  There is a 
special case usage of comma operator expressions that I would like to 
see disallowed and that is in the declaration of array dimensions, a 
confusing situation that I have mentioned before.

Recap:  What does the following declaration mean?

int[3,4,5] x;

Does this look like a 3 dimensional array declaration in any other 
language?  Of course it is not though (in D).

Cheers
Justin Johansson