[evolution] Add ISO/IEC 60559

[Tsche]

Content added

Adds ISO/IEC 60559 to evolution related standards.

Source URL: https://www.iso.org/standard/80985.html

[github-actions]

CI report

Commit 82fd1f5

Build

✅ Site built successfully. Download rendered site | logs

Frontend

No matching frontend workflow ran for this change.

Python

No matching python workflow ran for this change.

Other checks

• ✅ Check - Content and Data success. logs
• ✅ Check - YAML success. logs

✅ All completed checks passed.

[term-est]

What we are linking is quite useless
Nobody is going to buy this from ISO
Nobody is going to read the spec either, really

Plus the state of 60559 in C++ is already quite weird, Guy is trying to write an Annex F lately. It's a can of worms that is technically relevant, but relevance alone is too weak a bar for a curated resource page

C++ also has extended floating-point facilities such as std::bfloat16_t; we don't list every external standard or specification that is technically related to every facility in the language. I think that gives us a useful silverline: technical relevance alone shouldn't be sufficient; the resource should provide some practical value to someone visiting the site.

Otherwise we risk filling the site with authoritative-looking links for the sake of completeness, rather than resources that somebody would actually use.

I don't think we should have this in cppsocial. I am not quite sure about whether we need a whole title for related standards, or whether we should just mention to the sister standards and all briefly where relevant

[Tsche]

Plus the state of 60559 in C++ is already quite weird, Guy is trying to write an Annex F lately.

Possible future work on this does not matter here. Once Annex F (it can't be F, that's already used for Core UB) actually lands, we should just remove this reference entirely.

The evolution page is a bit weird anyway, it's kind of the only page that isn't targeting "the average user". Sure, people probably won't buy it from ISO but that is neither a concern we should worry about nor is that something we should provide bypasses for. Providing other ways to consume drafts of 14882 is fine - that's literally what this page is ultimately about (and let's be real - we do that anyway and not just on this site), but fucking ISO over unnecessarily does not seem like a great idea.

I would prefer to link IEEE 754 instead (since that's the canonical document number everyone knows), but we're an ISO committee, so we should probably use the ISO document number instead. I believe this was @eisenwave 's input on this during the first initial content upstreaming attempt.

[Tsche]

I think std::numeric_limits<T>::is_iec559 is reason enough to list it somewhere. But once again, not the ISO document number.

I'm surprised to not see it listed directly in the bibliography of the standard. It's only indirectly listed through ISO/IEC TS 18661-3:2015 (which references IEC559/ISO60559/IEEE754 directly).

[eisenwave]

What we are linking is quite useless
Nobody is going to buy this from ISO
Nobody is going to read the spec either, really

Agreed. I don't think we should be linking to paywalled content. It's already in the normative references of the standard for those who want to seek it out.

Possible future work on this does not matter here. Once Annex F (it can't be F, that's already used for Core UB) actually lands, we should just remove this reference entirely.

It can be annex F; the order of annexes can be changed before publication. Only the stable references ([ub]) are intended to stay stable.

I would prefer to link IEEE 754 instead (since that's the canonical document number everyone knows), but we're an ISO committee, so we should probably use the ISO document number instead. I believe this was @eisenwave 's input on this during the first initial content upstreaming attempt.

That's equally useless because it's equally paywalled. Overall, I would still prefer to link what is normatively referenced by the standard (60555), but if neither that nor any outside resource (754) provides something with value to site visitors, then why bother?

The evolution page is a bit weird anyway, it's kind of the only page that isn't targeting "the average user". Sure, people probably won't buy it from ISO but that is neither a concern we should worry about nor is that something we should provide bypasses for.

Ok, and why is it not a concern for us that the link we provide is as good as dead? I consider a paywall to be more or less a dead link.

Providing other ways to consume drafts of 14882 is fine - that's literally what this page is ultimately about (and let's be real - we do that anyway and not just on this site), but fucking ISO over unnecessarily does not seem like a great idea.

Not going out of our way to advertise their paywalled content is not "fucking ISO over", and it's far from unnecessary. Unless you're getting paid by ISO to advertise their store, we're making our collection of links actively worse by including paywalled content.

I'm surprised to not see it listed directly in the bibliography of the standard. It's only indirectly listed through ISO/IEC TS 18661-3:2015 (which references IEC559/ISO60559/IEEE754 directly).

Not sure what you mean. https://eel.is/c++draft/intro.refs links to ISO/IEC 60559.

[Tsche]

Ok, and why is it not a concern for us that the link we provide is as good as dead? I consider a paywall to be more or less a dead link.

I mean, I would prefer linking a freely available publication of these standards but I'm not sure if that's something we can do. Linking the canonical ISO project pages at least gives enough information to easily find it using your preferred piracy method (aka just punch the exact document number + pdf into google).

Not sure what you mean. https://eel.is/c++draft/intro.refs links to ISO/IEC 60559.

Ah, I was looking at the bibliography (https://eel.is/c++draft/bibliography).

[eisenwave]

Just link directly to Anna's Archive