On Sunday, 21 August 2016 at 17:26:24 UTC, Walter Bright wrote:
On 8/21/2016 2:47 AM, ag0aep6g wrote:
Upon use of the value, resolve which type to actually use for
it. If the
use type requests a type between least and most, use that
type for
evaluating the entire expression. If the use requests a type
outside
that range, use the one closest (and, if the use is below the
range,
complain about narrowing conversion).
So when only ubytes are involved, all calculations would be
done on ubytes, no
promotions, right? There are cases where that would give
different results than
doing promotions.
Consider `ubyte(255) * ubyte(2) / ubyte(2)`. If the operands
are promoted to a
larger type, you get 255 as the result. If they are not, you
have the equivalent
of `ubyte x = 255; x *= 2; x /= 2;` which gives you 127.
That's right.
The thing is, programmers are so used to C integral promotion
rules they often are completely unaware of them and how they
work, despite relying on them. This is what makes changing the
rules so pernicious and dangerous.
I've had to explain the promotion rules to professionals with
10 years of experience in C/C++, and finally stopped being
surprised at that.
D does change the rules, but only in a way that adds compile
time errors to them. So no surprises.
(Nobody knows how function overloading works in C++ either, but
that's forgivable :-) )
I have a speculative answer to the topic of this thread, which I
was wanting to write a comment here about, before I saw the last
two comments in this thread.
Look in the D Language Reference, the spec. Look for the word
"error" there. It occurs many times, in code that is erroneous in
the spec.
Also, notice the number of question marks in the code sample near
the end of the page on Declarations. Notice that the questions
raised are not answered there.
The D spec is full of errors, literally, or teasers sometimes. It
seems improbable to me that D will become popular unless that is
first fixed, and the attitude that it represents. It's a sign of
unsoundness, at least unsoundness about how to teach a language
or how to standardize it, that comes through clearly at a surface
level, even if someone doesn't have specific disagreements with
the design of D.
Erroneous code should be omitted from a spec, or at least clearly
marked such as by a red background.
Mixing lines commented as errors together with later lines
commented as "ok" in the same code quote blocks makes it even
more confusing. (Someone who doesn't know any D yet might even
think that D gives you the results of whatever lines are correct,
skipping the errors as if they were empty lines. Programming
languages differ enough that that's a possible feature, the sort
of feature that might result in a language being described as
"exciting" even.)
Anyone feel free to correct me or say I'm all wrong about this.
I'm not an expert on teaching programming languages. I'm just a
learner, and just as a hobby.