[Submission] D Slices

KennyTM~ kennytm at gmail.com
Tue May 31 13:25:30 PDT 2011


On Jun 1, 11 03:48, eles wrote:
>> This has been discussed a lot of times before. See
>> http://digitalmars.com/d/archives/digitalmars/D/
> About_switch_case_statements..._101110.html#N101112.
>
> Thank you. I know. I follow this newsgroup since the days when
> EvilOne Minayev was still posting here and also witnessed D 1.0 and
> old D group dying and the new digitalmars.D (because of Google
> indexing - while we are at indexes) and so on.
>
> I know this was discussing before. What I do not agree is the
> conclusion and the reason behind, which mainly is:
>
> "One of D's design policies is
>   that a D code that looks like C code should behave like C."
>
>
> Wel, is BAAAAD policy! Yes, if C code *is accepted as is*, then it
> should behave *like C*. I agree!
>
> But there is also a lot of C code that is simply *not accepted*. An I
> think it was Don Clugston that tracked down some time ago some
> strange and difficult bug caused by the fact that D was still
> accepting the C cumbersome syntax for declaring function pointers and
> arrays in the old style. Walter got rid of that syntax.
>
> So, the point is not about *accepting C-like code and imposing a
> different behavior* (which would be a distraction for C programmers
> and prone to bugs because old habits die hard) but *simply NOT accept
> some kind of C-code*. With errors and so on.
>
> Even for the existing C code, all that this is asking is to write
> some "fall" for those branches that do not have "break". Are there so
> many? Is this an overwhelming task?
>

I agree that implicit fall-through should be disallowed for a non-empty 
case. Also, the conclusion is "Walter thinks he uses fall-through 
frequently, so it should stay", not really because of C.


More information about the Digitalmars-d mailing list