Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I certainly hope that's where we're headed. The more we can tell the compiler about our code, the better. It might also be interesting to provide hints like "this int should only ever be in the range 1-30" :)


"this int should only ever be in the range 1-30"

That's in all the Pascal-family languages - Pascal, Modula, Ada.

"Perhaps the future of software isn't "rewrite everything in Rust", but instead we end up annotating existing C/C++ with borrow checking information."

Trying to retrofit this to C++ runs into the problem that too often you're lying to the language to get something done. Like extracting a raw pointer to be sent to a system call. You have to break a lot of existing code to make this work. Which means a new safer C++ like language. There are about five of those to choose from, none of which are used much.

Rust was right to do a clean break. But then they just got too weird, with their own brand of functional programming and their own brand of a type system.


I'd love to hear your thoughts on Rust having an in-house type system and functional programming paradigm. It doesn't seem all that different than comparable era languages like Swift (maybe through inspiration) or Haskell. Macros, are IMO, where things go a little wonky but once you learn you can actually trust the compiler it's easy to let go.


That's it exactly. If you're into Haskell or Swift, Rust isn't that strange. To a C or C++ or Go programmer, Rust is very strange.

Rust has some brilliant ideas, but it's too hard. Go is rather dumb, but good for getting server-side applications running.


Surprised to see that you put Swift in the same bucket as Haskell, since Swift is to me the prime example of successfully balancing power with usability in language design.

This is where languages like Haskell, Rust and others fail: the programming language nerds take over and design a language for themselves, making it weirder and weirder as time passes and new arcane features are added.


As a C++ programmer dabbling in Rust I don’t find it strange. Many of the core ideas were motivated by C++. But I also like Haskell too :)


> Trying to retrofit this to C++ runs into the problem that too often you're lying to the language to get something done.

you mean like the gigabytes of rust code just put in unsafe {} blocks or doing panic! when they don't know what to do with the error ? :p


This stuff has been out there for a long time, but it's never become popular outside of outside of safety-critical or high-integrity systems. Examples include:

Microsoft's C/C++ annotations: https://docs.microsoft.com/en-us/visualstudio/code-quality/u...

Ada's ranges: https://en.wikibooks.org/wiki/Ada_Programming/Types/range

Fun stuff to learn about in theory, but, unless you're working at a place where formal verification is part of the culture, good luck selling these tools to upper management.

More resources discussed here: http://highscalability.com/blog/2018/9/19/how-do-you-explain...


Ada's ranges are runtime checked right? How would you do this in a compiler?


Ada checks all arithmetic - the compiler can elide bounds checks if it can statically verify that no out of range error can happen, but if it can’t verify statically you get bounds checks at runtime.


a little of both iirc


you mean a contract https://en.cppreference.com/w/cpp/language/attributes/contra... c++20 has this, baring something unexpected happening in ISO.


Oh that looks awesome. I’ll definitely be using that once available, thanks for bringing it up!


Is this a baby version of dependent types?


I believe contracts are checked at runtime, so not really.


Contracts come in several forms. Some are checked at compile time. Some are checked at run time. Some the check is too expensive to actually run but is left for documentation. Compilers are expected to have a switch to turn off run time checking for production (just like assert)


Nothing in C++20 contracts requires any checking to be done at compile time. The only options currently required are runtime checking and no checking.


Contracts were designed so that they can be checked statically.

Pedantically you are correct: checking contracts is expected to be too expensive to actually do as part of a build. C++ expects that static analysis will check contracts as well (static analysis is might take 10 hours to check what compiles in 10 minutes)


C++ already had a level of dependent types for a long time.

    template<int N> 
    class T;

    constexpr int N = f();
    T<N> var;




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: