hard typdef - proposal - I know it's not in the standard

[Alec Teal]

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