Keith Thompson said:
Tim Rentsch said:
Keith Thompson said:
[...]
The usage in "implicit cast" isn't incorrect.
[...]
Yes, it is.
I'll say that a different way. It's accepted under regular informal
English (even with 'cast' having its usual technical meaning). People
might object to it as being technically bogus, or technically stupid,
or whatever, and technically they're probably right; however it is
still perfectly acceptable as informal English.
It's accepted in the same way that "irregardless" is accepted.
I would say the two cases are different. The word 'irregardless'
is an invented word, apparently appearing for the first time in
the early 20th century. In the phrase 'implicit cast', both
'implicit' and 'cast' are used in their normal senses. The
combination doesn't make literal sense, so at best the meaning of
such a phrase is idiomatic (and please note that I do _not_ mean
it's a standard idiom). However, it's easy to guess a meaning
that makes a sort of sense despite the apparent inconsistency of
the combination. In informal English these kinds of "irregular
meanings" and verbal shorthands happen all the time. A person
who uses "irregardless" just means a different word (although
whether the different word is "regardless" or "irrespective" we
don't always know). A person who uses the phrase "implicit cast"
means (in most cases) something different from "conversion" or
"cast", and also _for which there is no convenient existing word or
phrase_. My point isn't that the phrase is well-defined, indeed
it is not; rather, the construction that goes on to produce such
a phrase is commonly accepted in informal English. An example is
"deafening silence": literally this term makes no sense, yet the
combination can be understood (and has come to be understood) as
having a meaning different from the literal meaning of its
constitutent words. The construction began as being idiomatic;
over time and with greater usage the idiomatic phrase became a
standard idiom.
The term "implicit cast" *only* applies to C, so arguments about regular
informal English don't really apply; 99% of English speakers probably
don't know what a "cast" is in this context.
This statement presumes that "informal English" automatically implies
"non-technical English". That's a bad presumption: there is both
"formal technical English" and "informal technical English" (and also
the other two combinations). Formality and technicality (if I may be
allowed a little frivolous wordplay) are orthogonal aspects.
You seem to be making an artificial distinction between "technically
right" and "right". I don't agree that there is such a distinction.
I'm not saying -- more accurately, what I mean to be saying is not --
that 'implicit cast' as a phrase is either "right" or "technically
right"; rather it is that the construction is acceptable in informal
language. Is it the best phrase to convey what the speaker wants to
convey? That's impossible to say, because the phrase doesn't have a
well-defined meaning, nor do we know exactly what it is that the
speaker wants to convey (and indeed the speaker himself may not know
that exactly either). Despite that, the phrase may be successful
at conveying something of the intended meaning, and that process
works well enough so that similar sorts of phrasings are commonly
accepted in informal speech or writing.
And if the person is using words in a technically *imprecise* (i.e.,
wrong) way, he's likely to use a phrase like "implicit cast".
Imprecise is not the same as wrong. If I say the acceleration due
to Earth's gravity is 32 feet/second/second, that's a somewhat
imprecise statement, but it isn't necessarily a wrong statement;
whether it's right or wrong depends on what you think the error
bars are. Generally speaking, using informal language tends to
widen the error bars; indeed, not just widen, but also expand
their dimensionality outside the usual numerical dimensions and
into some linguistic dimensions.
So what's wrong with pointing out that "conversion" is a better and more
correct way to express the concept that was being expressed?
What's wrong is that it assumes that "conversion" (in the same
sense that the Standard uses the term) is what the speaker
wants to express, and more often than not that assumption
is (I believe) not consistent with the actual circumstances.
Or perhaps, at least often not consistent.
Really? You think it's right in _all_ cases? Doesn't
that seem like an overly strong claim? Please note, when
I say "trying to make such a distinction", I don't mean
they are consciously intending to do so; only that they
want to convey _something_ and what it is they want to
convey is not the same as what the Standard labels as
"conversions" (presumably of the implicit variety).
I don't even remember who used the term "implicit cast" in this
thread (and I hope he or she isn't feeling picked on now). But I
don't believe that person was making the distinction you're trying
to make, either explicitly or implicitly.
Oh, there's a good chance he wasn't, and in fact there's a good
chance that people who use the phrase may not be consciously aware
of exactly what they do mean. They may not even know that there
is a term "conversion", or know what it means exactly. But none
of that matters. What does matter is, whether they know what is
or not, what do they really mean? If what they mean is not exactly
the same as "conversion", it's wrong to say that the term for what
they mean is "conversion" -- because it isn't.
x[y] is equivalent to *(x+y) (add extra parentheses to taste).
We might say that there's an implicit addition and dereference; we
don't talk about an implicit "+" sign and an implicit "*" operator.
Unfortunately cast operations don't have analogous terminology to
addition/+ and dereference/*. The word 'cast' refers to both the
abstract operation and to the construction that symbolizes the
operation.
No, it does not. The word "cast" refers to an expression consisting
of an expression preceded by a parenthesized type name. The Standard
uses the term "Cast operators" in a section title, but doesn't define
it as far as I can tell; it's reasonable to assume that it refers
to the parenthesized type name that forms part of a cast expression.
The abstract operation is not a "cast"; it's a "conversion".
It's true these two notions are similar, but they aren't exactly
the same. "Conversion" covers a wider set than is covered by "the
set of operations performed by a cast operator". Incidentally, the
Standard uses all of "cast", "cast operation", and "cast operator".
If you look in 6.5.4p4 I think you'll agree that the Standard
defines "cast" to mean both the parenthesized type name _and_ the
expression whose value is to be operated on. So I think the best
fit for the earlier example would equate "cast operator" with "+",
"cast operation" with "addition", and "cast" with, hmmm, not sure,
"sum", maybe?
It's the rules of the Standard that dictate the source and target types
in both cases. It's just different rules.
It's hard to take this as a serious comment. Obviously the rules
of the Standard determine the result type in both cases. However,
in one case the result type is determined by the type or types of
the operands, but in the other case it's determined solely by the
operator. It is only in the case of cast-expressions [1] that the
result type is a function solely of the operation and not the
type(s) of the operands. The word "conversion" covers both cases;
"cast" covers only one.
[1] that is, cast-expressions with a cast operator in them.
Close, but not close enough. I don't see why we *need* a term for
"conversion plus choice of target type".
I wasn't trying to argue that there should be such a term. I'm
just saying, it's because there is no such term that the word
'cast' is used in 'implicit cast', rather than some other more
appropriate word.
And I'm unwilling to
give up the extremely useful existing term "cast", with its utterly
unambiguous meaning, for this concept.
It's important to understand that I'm not asking anyone to do so.
Actually, we already have a term for "conversion plus choice of
target type". It's the phrase "conversion plus choice of target
type".
Three problems with this. One, this phrase is obviously just too
long to be useful. Two, the people who are likely to use the
phrase 'implicit cast' are likely also not to be familiar enough
with C jargon to latch on to this. Three, most important, what
we need is a term for a related but different notion, that one
kind of value is implicitly interoperable with another kind.
In fact, "implicitly interoperable" or "implicitly assignable"
might be worth considering as terms to describe the sort of
thing that is meant by people who use 'implicit cast' now.
