On 28/01/13 02:38, James Dennett wrote:
That's a cast -- an explicit request in code for a type conversion.
The fact that it's a pure compile-time operation and a no-op at
runtime has no bearing on whether it "is a cast", just as we can
static_cast beween enumerators and integers today with no run-time
cost. One of the purposes of casts is to tell the compiler "Yes, I
mean to write this", and it's common for casts to be purely
compile-time operations. n3515 is also explicit that the permitted
conversions have no run-time cost. Is there anything that you propose
that a "private opaque alias" from n3515 does not provide? -- James
No, it's the other way around, n3515 provides stuff this doesn't - but
by design. It's not an "either or".
(I've deleted like 3 different responses now).
It really isn't an "either or", I am not saying "this over n3515", I
would want both (I think, that's the point of this discussion).
I would prefer a hard-typedef for things like vector components (if I
didn't decide to use a struct, where the components would be given by
name), or ids, the compiler would stop me mixing types unless I meant
to, the very nature of just putting the word "hard" before a typedef is
something I find appealing as the function of it is to stop me from
doing silly things and to allow me to be reminded of what something is
from it's definition (a BookId for example), it'll also allow
overloading, I find the idea of a function called "getName" returning
the name of a book, author or whatever very appealing when passed a
BookId, AuthorId or a whateverId.
The very nature of a typedef is an alias, if I alias something from an
int I have grown to expect to be able to add it and do other integer
things with it, this is true of the hard-typedef to, I don't want to (I
may have said this) be able to define a type system so rigid that an IDE
auto-complete could create a grand unified theory. I don't want to stop
and think when using this on a float type "can I divide this", not all
operations form a group (this is why I mentioned groups earlier), real
numbers do not form a group under multiplication (and hence division by
requirement of an inverse) because of 0 being a real number. Despite
this we may still divide by zero. I do not want to have to use n3515 and
be faced with this temptation. Having said that I have yet to use it so
maybe it wouldn't be that big.
That is why I'd want both, but at least in my mind n3515 would be nearer
to "if I really wanted it I could use classes" than the hard-typedef.
I may have said this too, but I'll say it again. Typedefs are something
that go on a line and define a useful alias. I doubt this is disputed,
sticking the word "hard" before it and gaining this is something I find
very appealing, having to write:
using opaque-type = access-specifier underlying-class {
desired-member-trampoline-signature = default;
friend desired-nonmember-trampoline-signature = default;
};
(or something of that form)
while useful, is less appealing. I don't really care that I /could/ add
BookIds, I think the hard-typedef is more in line with how typedefs are
actually used, but abstract algebra has taught me that you cannot
rigidly define operations on things that'll always be defined or even
useful, I also see operators more as a notation than operations, I think
this is what tempts people and luls them into needlessly defining
operators, adding two BookIds doesn't have to mean the operation of
addition on integers. I am going off topic, suffice to say perhaps I
will think of a use for additive notation for a binary operation on
BookIds, it need not be the same as addition on integers. If I did
define such a thing though doesn't this blur the line between class and
a hard-or-strong typedef?
Alec
