IOC is inside Clang-head

[Maxim Fomin]

On Tuesday, 29 January 2013 at 19:21:34 UTC, Walter Bright wrote:
> On 1/29/2013 8:48 AM, deadalnix wrote:
>> Is that a practical limitation ? All widespread arch I know 
>> assembly for are 2
>> complement, and it seems like something settled now in the 
>> field. Or am I
>> unaware of some important stuff ?
>
> One's complement machines existed when I was a wee laddie, but 
> I haven't heard of any since.
>
> C (and C++) also "support" things like bytes that are larger 
> than 8 bits. Yes, there are >8 bit byte CPUs in the form of 
> specialized DSP processors, and yes, there are C compilers for 
> them.
>
> But I can't think of a single non-trivial C program that could 
> be compiled for greater than 8 bit bytes without extensive 
> refactoring, so having Standard C "support" such is mostly an 
> exercise in theater and is useless in real life.
>
> Even worse is all the millions of man-hours wasted in (usually 
> incorrectly) trying to make C code portable to theoretical C 
> compilers that have ints larger than 32 bits, etc., trying to 
> ensure that modern C code will work on a 16 bit C compiler, and 
> on and on.

Fully agree here. C support such things for sake of greater 
portability, however I consider that such support really hurts 
portability, than enhances it.

> By defining these problems out of existence, D achieves a major 
> simplification in terms of programming bugs that are far more 
> theoretical than real.
>
> One real issue is order of evaluation bugs, but I didn't see a 
> note about that in the Clang list.

After experiencing with C and before joining D, I came to the 
same conclusion - a new language should reconsider attitude to 
portability in a sense that it should not support 1% and damaging 
99%.