null [re: spec#]

bearophile bearophileHUGS at lycos.com
Sat Nov 6 06:49:09 PDT 2010


steveh:

> I've known there are hidden tradeoffs when using these 'intelligent' types.

Right, every design has some trade-offs.


> Non-null types add terrible runtime checks everywhere.

This is not true. They may "add" some runtime checks, but in practice you normally need to perform those cheeks anyway, manually. In practice I think nonnull types may even reduce a bit the total number of cheeks present in critical paths (because if you have a nonnull, there is no need to test it again and again, once is enough).


> It's simply not acceptable in a systems programming language. Operating system kernel uses very efficient uninitialized arrays for buffers. It's crazy to force this non-null hype down our throats.

You are just not following the discussion and the things said. The normal pointers and references will keep being used in the same way and they will have no runtime cheeks (the compiler in safe modules may ask in some way for them to be tested before being used, this is a point not discussed enough yet in this thread).


> I fail to see why non-null is needed.

Huge C programs show that many features of D aren't actually necessary, you are able to program and live without them. But I think in theory nonull reference types may help avoid some bug.


> Sometimes even immutability seems too difficult.

It is :-)


> You can write safe code, you can write efficient code, and you can write simple code. But these can't be the same code!

I agree that those are three things difficult to have at the same time. But I think D may allow you to pick two as you like, this is the good thing.


> Is Spec# used anywhere?

It's used in some universities to teach some ideas it contains. It has created the Contracts of C#4 and a verified C compiler, so even if Spec# dies today, it has done more than 98% of other languages invented so far.


> We should forget it.

Good ideas should be listened to despite the success of the language that contains them. History of computer languages if *full* of failed languages that have taught ideas to more successful languages. If you ignore the ideas just because they come from a failed language, they you are shutting yourself 95% of the progress and development in the story of language design :-)

Bye,
bearophile


More information about the Digitalmars-d mailing list