"Also sprach Vincent Lefevre:" > On 2018-02-06 23:49:42 +0000, Peter T. Breuer wrote: > > An interesting new theory, if late to the party. You now say that the > > phrase "the usual arithmetic conversions" (6.3.1.8) must be present in > > the subsection relating to the operator? > > This is implied by what is said at the beginning of 6.3 (which 6.3.1.8 > belongs to): Yes. I've just been reading what seems like only the first few hundred pages of the standard (it's not that bad - they leave big spaces between lines) and I've got to there too. It's before the subsections we've been looking at, and it lays down in general terms how one should go about constructing a semantics from the bits and bobs scattered around the rest of the room. That's what is required. There is also a bit to that effect at the start of the standard where it names SHALL and SHALL NOT as the keywords they use for must/must not. They don't have a may/may not in keywords, but there is a confusing kerfuffle about strictly conforming, conforming, hosted, and freestanding that may logically amount to it, if anyone cares. I'll quote the paragraph starting 6.3 in full (my caps): SEVERAL operators convert operand values from one type to another AUTOMATICALLY. THIS subclause specifies the result required from SUCH an implicit conversion, as well as those that result from a cast operation (an explicit conversion). The LIST in 6.3.1.8 summarizes the conversions performed by MOST ordinary operators; it is SUPPLEMENTED as required by the discussion of each operator in 6.5. > "Several operators convert operand values from one type to another > ^^^^^^^ > automatically." > > "Several", not "All". And 2 sentences later: Yes, but your analysis is not complete. First, you are right that this sentence weasels out of being prescriptive with "several", but it's not a prescriptive sentence in the first place, just a descriptive one, so we shouldn't be looking to it for instruction. It's really intended as a warning that we should be prepared to see stuff about CONVERSION coming up, and (1) the AUTOMATICALLY that we will see does not refer to the application of THESE instructions, but to the compiletime process and the absence of an EXPLICIT instruction in source code (as the next sentence further expounds). "automatically = not explicit" is the thing it tells us there. The NEXT sentence tells us also that "explicit = cast". So we know that (1) autmatically/implicit are words to be applied for "no cast", and (2) explicit is a word that means "cast". That's all there is of substance in the first two sentences. The final sentence is a killer that puts aside the hint of weaselity in the first sentence by telling us exactly how we are to figure out conversions. We are first to look at a list in 6.3.1.8 to see what is up, but we are to override that or fill in undefined areas with specifics from 6.5. That's all. Nothing else, and so this IS prescriptive. There's stuff I've left out like the "SUCH" leaving it open that there are implicit conversions that are not automatic. Somebody bear that in mind (not me!). But I'll go with automatic implies implicit, and try not to lean on the converse. > "The list in 6.3.1.8 summarizes the conversions performed by > most ordinary operators;" > ^^^^ > > "most", not "all". Yes, but that's meaningless if they're going to leave it at that, and they don't. > So, you may wonder: Where do I get more detailed information about > when this is done? The answer is at the end of the sentence: > > "it is supplemented as required by the discussion of each operator > in 6.5." > > So it says that you need to look at 6.5, which is... that: No. It says to look at the list, which applies in the absence of being countermanded (or supplemented) in 6.5. The "most" is to acknowledge the list possibly not being prescriptive because of that exception. We know that because no other means of constructing the semantics is given. That's it. All. No more. It's the list or the details in 6.5 or nothing, zilch, fin. > > Ingenious, and I'll look at that as a possibility. Let's test. > > According to the index, the phrase occurs in > > > > usual arithmetic conversions, 6.3.1.8 [defn], 6.5.5, 6.5.6, > > 6.5.8, 6.5.9, 6.5.10, 6.5.11, 6.5.12, 6.5.15 > > > > 6.5.5 = multiplicative ops (* / %) > > 6.5.6 = additive ops (+ -) > > 6.5.8 = order relations (> < <= >=) > > 6.5.9 = equals relns > > 6.5.10= bitwise & > > 6.5.11= bitwise ^ > > 6.5.12= bitwise | > > 6.5.15= ternery op ?: > > > > That looks plausible. 6.5.7 (>> and <<) is about all that's missing. > > Now, aren't you eventually convinced? Of what? What is required is REASONING. It has not been presented so there has been nothing to be convinced of. > Note that 6.3.1.8 also says: "Many operators...". "Many", not "All". Umm .. what is 6.3.1.8? Oh, that's the list. It doesn't matter what it tries to say in 6.3.1.8 because we already have it from the paragraph I quoted above from the start of 6.3 that the list in 6.3.1.8 is prescriptive, except as it is countermanded and supplemented in 6.5. And "many operators" would be meaningless, so I think we should take what they have written down as pretty much it. That's useful to me. I had given the same generic compiler construction for * /, but a different one for % (because it's doable as (a/b)* b - a), and so I'll join those up and treat them as a single group (note to self :-). I also had + - treated by the same generic construction, so that's right. I had order and equals relations grouped together so I'll examine that to see if there's a difference worth mentioning and maybe separate order and equals if so (note to self). I had the bitwise logical operations and >> << treated by the same generic construction, so I'll look at those and see if they need separate treatment (note ...) The ternery op was treated separately anyway, just because 3 != 2. Complement and negate unaries need looking at too. OK, plenty to do before lunch. Regards PTB
