Thank you for your feedback. How would you suggest that I should have responded to this issue instead? I agree that my response was authoritative, but I believe that is what was asked (the issue is seeking an authoritative “official” answer). And from the perspective of not wanting to break this person’s code (or anyone who stumbles upon similar advice), the authoritative “official” answer is an unequivocal no, “this is not supported”, as the name of the property states. Though, like I mentioned, we can’t really tell anyone what to do in their own code, so at best we can say what’s supported and what’s not.
I'm sorry, but your comment wasn't clear. What assumption am I making? I mean, I'm sure I made several, but which do you think needs to be evaluated/supported?
> 1. It gives a range of 3 permissible options. If one of these "permissible" options is "you can do anything", what are the other 2 options doing on that list?
Before the list it clearly says, "behavior, [... when UB occurs elided ...], for which the Standard imposes no requirements."
How can it both impose no requirements, yet simultaneously impose a requirement that it come out of that list of three options?
> That this somehow (how?) means "I can do anything" is purely your interpretation.
It's essentially unknowable if anybody has produced code out there that is like this, but the point still stands that it is valid code.
If you want to uphold a commitment to backwards compatibility, you simply cannot extend your language in a way that might possibly change the behavior of valid-but-nonsensical code in the wild.
The article indicates its not officially supported, although it could be.
Ian Lance Taylor replied that the behavior is
undefined, but so far stable. His suggestion was
to open a bug and request that this desirable (!!!)
behavior be explicitly permitted.
You're right on one point: the standard is very explicit.
And because it is explicit—a fact you yourself just admitted—the fact that silent erasure of non-dead code is not a listed option in response to UB means that it is not allowed.
How so? "You acknowledge that X is not designed or intended for use in Y" is not a restriction on using X for Y: it's just telling you in no uncertain terms that the developers of X will not be helping you with any issues if it turns out you are using it for Y. This looks like the exact situation that OP is in, and that the Java provision is designed to guard against.
So, we have a "standard" which says that both behaviors should be supported, and there should be two different ways to express them, but explicitly declines to say which does what?
I'm genuinely not sure what purpose this particular standard serves, but it looks like it's not allowing people to write portable code...
Now, see, that worries me right there. Because its just something a code-review obstructionist would say. They probably wrote the guidlines too.
It doesn't matter how you do those simple things. Almost always. If a case arrises where it does matter and somebody uses the wrong one, then by all means bring it up. Otherwise, hit Approve and move on.
As long as it doesn't violate the spec, I'd look at actual performance results of it. I.e. if it interferes with usage or creates some kind of performance degradation for the applications, then it's indeed a problem. Otherwise this requirement should have been an explicit part of the spec.
I.e. I'd imagine if this is a real problem, there should be some RFC for the updated version of the API where this is prohibited or some requirements are added about how to control it.
it would definitely be a design issue if the extension could only support a single index type, but Andrew already has plans to implement HNSW in 0.5.0:
> it's not spec-compliant for servers to parse and interpret this data.
That's wrong. A lot of people just don't understand the difference between SHOULD and MUST when reading standards. The standard just says that you shouldn't rely on servers accepting it unless they tell you.
reply