Who wishes for typecpy in addition to typedef?

[Keith H Duggar]

Often I've felt that the ability to alias an existing type where the
alias would be treated as a different type thus allowing overloading,
etc would be very useful.

typedef : alias an existing type Foo as Bar where Bar is a Foo
typecpy : alias an existing type Foo as Bar where Bar is not a Foo

Here is a simple example :

typecpy std::valarray<double> RowVector ;
typecpy std::valarray<double> ColVector ;

This would allow you grab all the existing functionality of valarray
and at the same time overload, for example, the arithmetic operators
to act differently on column and row vectors. If you try to gain this
funtionality by inheritance :

class RowVector : public std::valarray<double> { ... }
class RowVector : public std::valarray<double> { ... }

then you are forced to tediously rewrite or forward all of the
valarray constructors.

Actually, in my experience I have run into many cases where typecpy
would save time, code, and effort. I know at least some others share
this feeling. For example in a 1999 thread suggesting the removal of
typedef Dave Harris wrote :

Sometimes I want a new type, and sometimes I want a new name for an
existing type. Not having a good mechanism for doing the former is a
problem, but typedef is still needed for the latter.

Ideally we might have 2 keywords, eg:
typedef - define a new type.
typename - give a new name to an existing type.

although for backwards compatibility typedef is unlikely to change now.

Do any of you think you would benefit from typecpy or think it is a
good idea? Any not?

I'm no compiler expert but it seems that this extension would be
almost trivial to implement. Is that accurate?

The only sticky point I can think of would be in deciding how typecpy
would interact with inheritance. For example :

class Base { ... } ;
class Derv : public Base { ... } ;

typecpy Derv Copy ;

Should Copy be considered a Base?

It seems to me the easiest solution would be to say that Copy is a
Base. In other words, Copy is exactly what you would get if you
exactly copied Derv's declaration and definition and then replaced the
word Derv with Copy.

Wouldn't that be a very easy and useful extension to implement?

Can you think of cases were typecpy would be useful to you?

 

[Jonathan Turkanis]

Often I've felt that the ability to alias an existing type where the
alias would be treated as a different type thus allowing overloading,
etc would be very useful.

The same proposal was made at comp.std.c++ today. Here's my reply:

---------------------

Ada has a possibility to derive a new type from an existing one.
Derived type behaves like original, but, unlike a type defined by typedef,
can't be used interchangeably with another derived types (unless
explicitly casted). Why C++ does not have such possibility ?
Suppose that we define such types like typedef, using "newtype" keyword:
newtype int MONEY_T;
newtype int WEIGHT_T;

You seem to be advocating "strong typedefs". This has been discussed
for C++, with the following syntax:

strong_typedef int money_t;
strong_typedef int weight_t;

See "Asepcts of Forwarding" by Lois Goldthwaite
(http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1395.txt).

Jonathan

 

[Keith H Duggar]

Hey that's exactly want I want. Thanks Jonathan. I hope it is added
and I hope they call it something shorter than strong_typedef. typecpy
seems perfect.

 

[Jonathan Turkanis]

Hey that's exactly want I want. Thanks Jonathan. I hope it is added
and I hope they call it something shorter than strong_typedef. typecpy
seems perfect.

No problem. It's hard to tell from that note how well received the
idea is and what its chances are.

Jonathan

 

[Attila Feher]

Often I've felt that the ability to alias an existing type where the
alias would be treated as a different type thus allowing overloading,
etc would be very useful. [SNIP]
Wouldn't that be a very easy and useful extension to implement?

There have been many discussions about this. The answer is: it might be
easy to implement, but it has zero legit use.

Can you think of cases were typecpy would be useful to you?

Nope. There were times when I thought it would make sense, but as it turns
out it makes absolutely no sense. If you want a new type, that new type
will always be different from the other one - in other ways than its name.

 

[Keith H Duggar]

Can you think of cases were typecpy would be useful to you?

Nope. There were times when I thought it would make sense, but as it turns
out it makes absolutely no sense. If you want a new type, that new type
will always be different from the other one - in other ways than its name.

Interesting. It's a kind of mirage feature. You think it would be
useful but then when you look closer it disappears. You are right that
it has been discussed a lot I was just looking in the wrong group.
comp.std.c++ has a lot of material regarding it.

 

[Attila Feher]

Interesting. It's a kind of mirage feature. You think it would be
useful but then when you look closer it disappears. You are right that
it has been discussed a lot I was just looking in the wrong group.
comp.std.c++ has a lot of material regarding it.

Usually there are very few places where it seems to be useful, and basically
it is nearly always around "fundamental" types, where I say "fundamental",
because string belongs here as well. For string, you wish for it, so that
you do not need to make all the constructors by hand. But then again you
soon find out, that:

1.) There are motions to create such inheritance where constructors are
"inherited"

2.) You will need more change than just the type name

3.) It is usually a bad idea to inherit from string, instead of containing
one. You "get too much" functionality

4.) Simple name change either creates an unrelated new type (there is not
way to change it) or a new type, which can be converted to string. In the
first case: you cannot use it as a string without serious casting business,
in the latter case you loose type safety.

The _only_ place where it seems (at first sight) to make sense to me now is
to create new (standard) size types, on which you can overload. But, then
again, I can easily imagine that if I start to think about it a bit more, it
will turn out to be useless as well. IIRC right now, the size_type member
typedef of all (most?) standard library elements (providing it) "translates"
to std::size_t. So it is not possible to overload anything. OTOH it may
not make sense either, since if I use a size value "alone", it is just a
size. Without seeing the container itself one cannot really do container
dependent things with it...