4 ms·

The analogy is fun, but I'm not sure I agree with the author's conclusion: > a constexpr marker should be unnecessary, just like a hypothetical linux marker I

by catern 5y ago

The analogy is fun, but I'm not sure I agree with the author's conclusion: > a constexpr marker should be unnecessary, just like a hypothetical linux marker In fact, I'd love to have a "linux" annotation for functions which can only be called on Linux! Using the type system to manage the context in which a function can be called is a good idea, and allows safer code. The alternative is global type inference (which is slow) or runtime failures (which defeats the point).

klodolph 5y ago
I thought the author's conclusion was that constexpr annotations were necessary?
- catern 5y ago
  No, they quite clearly say the opposite, I edited my comment to quote the post.
  - klodolph 5y ago
    Interesting, I see that in the conclusion. Seems to me that the conclusion and the body of the article disagree.
runevault 5y ago
I agree. He made a point that, if I understood I agree with, that constexpr is not necessarily as strict as it should be. Specifically that you only need ONE path to work at compile time to be able to be constexpr. I might be missing a reason this is a good idea but at least to me it seems bizarre. It would 100% be nice if code could be tagged by context in more ways than constexpr so the compiler can better tell you things like "put this behind an ifdef for Linux" etc (maybe with a compiler option to say this will only ever target one context and you don't need to check for that).
tialaramex 5y ago
In Rust you can tag a function with arbitrary configuration parameters, it's common to write #[cfg(unix)] but you could equally write #[cfg(linux)] It's just that you're much less likely to need to say this. For example OSStr (borrowed reference to the Operating System specific string type) has #[cfg(unix)] reflecting APIs that make sense for a Unix-style string while #[cfg(windows)] wraps APIs that make sense if your operating system once thought characters are a u16. But the ordinary str and String don't have such APIs, you have to explicitly tell the language "I need this gross non-portable stuff" before you have to start using macros to get to the specific platform dependant elements. I suspect you could do a similar trick in C++ but it may not be standardised anywhere.
- pornel 5y ago
  Moreover, Rust is working on portability lints: https://github.com/rust-lang/rfcs/blob/master/text/1868-portability-lint.md https://github.com/rust-lang/rfcs/blob/master/text/1868-port... So that even when you only compile and test your code on Linux, you will get warnings about calling Linux-only functions from maybe-Windows functions.
  - comex 5y ago
    For some definition of “working on”. The RFC was accepted several years ago, but nobody has stepped forward to actually implement it.
pjc50 5y ago
You can do that in C# : https://docs.microsoft.com/en-us/dotnet/api/system.runtime.versioning.supportedosplatformattribute?view=net-5.0 https://docs.microsoft.com/en-us/dotnet/api/system.runtime.v... (Strictly it's an attribute rather than a type, but it's enforced by the compiler given a target runtime)

by catern 5y ago

klodolph 5y ago

I thought the author's conclusion was that constexpr annotations were necessary?

catern 5y ago
No, they quite clearly say the opposite, I edited my comment to quote the post.
- klodolph 5y ago
  Interesting, I see that in the conclusion. Seems to me that the conclusion and the body of the article disagree.

runevault 5y ago

I agree. He made a point that, if I understood I agree with, that constexpr is not necessarily as strict as it should be. Specifically that you only need ONE path to work at compile time to be able to be constexpr. I might be missing a reason this is a good idea but at least to me it seems bizarre. It would 100% be nice if code could be tagged by context in more ways than constexpr so the compiler can better tell you things like "put this behind an ifdef for Linux" etc (maybe with a compiler option to say this will only ever target one context and you don't need to check for that).

tialaramex 5y ago

In Rust you can tag a function with arbitrary configuration parameters, it's common to write #[cfg(unix)] but you could equally write #[cfg(linux)] It's just that you're much less likely to need to say this. For example OSStr (borrowed reference to the Operating System specific string type) has #[cfg(unix)] reflecting APIs that make sense for a Unix-style string while #[cfg(windows)] wraps APIs that make sense if your operating system once thought characters are a u16. But the ordinary str and String don't have such APIs, you have to explicitly tell the language "I need this gross non-portable stuff" before you have to start using macros to get to the specific platform dependant elements. I suspect you could do a similar trick in C++ but it may not be standardised anywhere.

pornel 5y ago
Moreover, Rust is working on portability lints: https://github.com/rust-lang/rfcs/blob/master/text/1868-portability-lint.md https://github.com/rust-lang/rfcs/blob/master/text/1868-port... So that even when you only compile and test your code on Linux, you will get warnings about calling Linux-only functions from maybe-Windows functions.
- comex 5y ago
  For some definition of “working on”. The RFC was accepted several years ago, but nobody has stepped forward to actually implement it.

pjc50 5y ago

You can do that in C# : https://docs.microsoft.com/en-us/dotnet/api/system.runtime.versioning.supportedosplatformattribute?view=net-5.0 https://docs.microsoft.com/en-us/dotnet/api/system.runtime.v... (Strictly it's an attribute rather than a type, but it's enforced by the compiler given a target runtime)