> And about C# checked: http://msdn.microsoft.com/ru-ru/library/74b4xzyw.aspx
> By default it is only for constants. For expressions in runtime it must be explicitly enabled.

en link: http://msdn.microsoft.com/en-us/library/74b4xzyw.aspx

On Wednesday, 12 December 2012 at 02:44:42 UTC, Walter Bright wrote:
> UDAs are a primo example of this.

OT: Why those are not allowed on module decls and local decls? We can't use UDAs on decls in unittest blocks. We can't use a UDA to mark a module reflectable, can't put an attribute on a "voldemort" type, etc. Please don't introduce arbitrary restrictions. That way you exclude many valid potential use cases, a recurring pattern that constantly pisses of D users. Features should be as general as reasonably possible. Otherwise, they *do* make us go herculean lengths.

On Wednesday, 12 December 2012 at 08:00:09 UTC, Walter Bright wrote:
> On 12/11/2012 11:53 PM, Walter Bright wrote:
>> On 12/11/2012 11:47 PM, Han wrote:
>>> Walter Bright wrote:
>>>
>>>> ML has been around for 30-40 years, and has failed to catch on.
>>>
>>> Isn't D on that same historical path?
>>
>> Many languages wander in the wilderness for years before they catch on.
>>
>
> BTW, many rock bands burst out of nowhere on the scene with instant success. Overlooked is the previous 10 years the band struggled in obscurity.
>
> This includes bands like The Beatles. Well, 6 years for The Beatles.

Led Zep, too. Long time ago I read some pseudo-scientific book called "Heavy Metal" (don't remember the author) who claimed it is a rule: a couple of fans in the beginning, several years of desperation and only after that - fame and fortune. Of course, the reality as much more complex.

On Wednesday, 12 December 2012 at 14:39:40 UTC, Michael wrote:
> Machine/hardware have a explicitly defined register size and does know nothing about sign and data type. fastest operation is unsigned and fits to register size.

Frankly, the hardware knows nothing about classes and about virtual methods, neither.

The question is: why the DEVELOPER should know about that register size? There are many other things that the developer is unaware of (read SSE instructions) and those are optimized behind his back.

The choice to promote to the fastest type is a sweet thing for the compiler, but a burden for the developer.

OTOH, I *never* asked for compulsory promotion, just mimicking it. (in fact, I was not asking for anything, just addressed a question) The idea is to guarantee, by the compiler, that the final result of an integral arithmetic expression is AS IF all integrals there are promoted to some widest-integral type.

Actual promotion would be made only if the compiler believes that's really necessary.

In the current implementattion too, speed is lost as long as you have a long there, as you need promotion further than int.

> OTOH, I *never* asked for compulsory promotion, just mimicking it. (in fact, I was not asking for anything, just addressed a question) The idea is to guarantee, by the compiler, that the final result of an integral arithmetic expression is AS IF all integrals there are promoted to some widest-integral type.

And the question is exactly that: what are the reasons to favor one view over another? (that is int-C over int-FPC)

Is FPC that slow? Is C that easy? Weighting pro and cons?

On 12/12/2012 03:45 AM, Walter Bright wrote:
> On 12/11/2012 5:05 PM, bearophile wrote:
>> Walter Bright:
>>
>>> ML has been around for 30-40 years, and has failed to catch on.
>>
>> OcaML, Haskell, F#, and so on are all languages derived more or less
>> directly
>> from ML, that share many of its ideas. Has Haskell caught on? :-)
>
> Haskell is the language that everyone loves to learn and talk about, and
> few actually use.
>
> And it's significantly slower than D,

(Sufficiently sane) languages are not slow or fast and I think the factor GHC/DMD cannot be more than about 2 or 3 for roughly equivalently written imperative code.

Furthermore no D implementation has any kind of useful performance for lazy functional style D code.

In some ways, D is very significantly slower than Haskell. The compilers optimize specific coding styles better than others.

> in unfixable ways.
>

I disagree. That is certainly fixable. It is a mere QOI issue.

I read all thread and conclude that developers want a one button - 'do all what I need'.

As mentioned above, for example, python have a arbitrary int (that implemented as C library ;)).

C can be used on many platforms. For each platform developer have solution as library. Right way is creating something new instead cutting something that exist.

Each platform have a own limitations: memory, execution time etc.
It's good if different platforms can communicate between each other.

Not all algorithms consume a lots of memory or have needs in arbitrary int.

In some cases we have + or -. Good/right way is "-" -> library solution -> "+" .
Language features are fundamental features.

On 12/12/2012 2:53 AM, foobar wrote:
> One example that comes to mind is the
> future version of JavaScript is implemented in ML.

Um, there are many implementations of Javascript. In fact, I have implemented it in both C++ and D.

> For each platform developer have solution as library. Right way is creating something new instead cutting something that exist.

Moving some of the things to from the library to the language is hard and limitating, but sometimes it worths the effort.

An example: threads. C/C++ have those as external library (not speaking about standard library here), as pthreads, for example. This is very nice, but limits the degree to which the compiler is able to optimize and to check the correctness of code, since the very notion/concept of thread is alien to it.

Such library can be optimized just with respect to one compiler, at most.

Take Java or D: here, threads are part of the language/standard library. Compiler *knows* about them and about what can do with them.

There is a trade-off.

(This issue is a bit off-topic, but it shows why it is important that some things should be *standard*)

On 12/12/2012 4:51 AM, Araq wrote:
>  From http://embed.cs.utah.edu/ioc/
>
> " Examples of undefined integer overflows we have reported:
>
>      An SQLite bug
>      Some problems in SafeInt
>      GNU MPC
>      PHP
>      Firefox
>      GCC
>      PostgreSQL
>      LLVM
>      Python
>
> We also reported bugs to BIND and OpenSSL. Most of the SPEC CPU 2006 benchmarks
> contain undefined overflows."

Thanks, this is interesting information.


> So how does D improve on C's model? If signed integers are required to wrap
> around in D (no undefined behaviour), you also prevent some otherwise possible
> optimizations (there is a reason it's still undefined behaviour in C).

D requires 2's complement arithmetic, it does not support 1's complement as C does.