Gregory's Server@pinskia @scherzog @crazyeddie @lina I may have been in the wrong, I didn't know GNU extension where specified. I still don't think that spec are needed, just good documentation.
|
10 comments
@Conan_Kudo @pinskia @scherzog @crazyeddie @lina How is a spec more valuable than documentation? And UB are unfortunately underspecified in Rust, C and C++. We don't have a complete list for any of those languages.  @robinm @pinskia @scherzog @crazyeddie @lina Well, a spec *is* documentation. But I imagine that's not what you meant, and you refer to usage documentation (e.g. documenting how to consume it rather than what it is). But you need both for a good picture of the language you are using. Rust has great usage documentation but crap documentation about Rust *itself*. And that can be a problem when you hit weird edges that you need clarity to resolve. @Conan_Kudo @pinskia @scherzog @crazyeddie @lina I'm surprised because I read a lot of C++ papers (I'd about 5% of them since many years) for fun, but I never needed to refer to them to resolve issue when using C++. However I do use cppreference.com a lot. And the only time I did not found what I needed in cppreference and had to open the corresponding paper (it was about deducing this), I just read the usage example, lot the implementation notes in legalized language. @robinm @pinskia @scherzog @crazyeddie @lina At least for me, it's rare that I go back to the spec documentation, but when I have to, it's mostly to understand the intent of things and what the constraints they designed it for. But I know people that use that same information to come up with "tricks" to squeeze out everything from the language without breaking things. (I'm also glad I don't live in that world where I need to think of that! 😂) @Conan_Kudo @pinskia @scherzog @crazyeddie @lina In your case, aren't the Rust RFC enough, or does divergeance between when they where accepted and the real implementation too much? And when you speak about squeezing out everything from the language feels like compiler work (which isn't an issue if there is a single blessed implementation) than application/library work, or do I miss something? @robinm @pinskia @scherzog @crazyeddie @lina Sometimes the divergence is meaningful between RFC and implementation. And even with a single compiler implementation, squeezing everything out the language matters. Because if you don't know what is safe to squeeze, the assumption can be violated in an upcoming revision without any real warning. It's the equivalent of dealing with nightly/unstable rust features. I'm also for having multiple compiler implementations, which is way harder with no spec. @Conan_Kudo @pinskia @scherzog @crazyeddie @lina Makes sence. thanks for the detailled explanation.  @robinm @Conan_Kudo @pinskia @scherzog @lina C++ has some really deep ends that you'll only be able to resolve by looking at the standard. I think the most obscure one I helped answer was a guy trying to disable a copy constructor but allow construction via an implicit cast operator on the same type--or something...weird thing to do, but why wasn't the compiler allowing it?? It's this weird rule in the standard language that tosses every other possible resolution BUT copy out of even lookup. @crazyeddie @robinm @Conan_Kudo @scherzog @lina Even in a small language like P4 (which has a specifications), there are many corner cases that don't get flushed out always (in both the spec and the compiler). Examples for the spec were https://github.com/p4lang/p4-spec/pull/1076 https://github.com/p4lang/p4-spec/issues/1096, https://github.com/p4lang/p4-spec/issues/1037 (you can look up the reference compiler issues too). |
@robinm @pinskia @scherzog @crazyeddie @lina For a programming language, a specification is actually really important. It resolves ambiguities and also defines where ambiguities are. People argue about undefined behavior problems because we *know* where those are. And that's incredibly valuable.