discrimination of constructors with same number of parameters

spir denis.spir at gmail.com
Thu Dec 30 05:33:00 PST 2010


On Thu, 30 Dec 2010 10:07:58 -0200
Guilherme Vieira <n2.nitrogen at gmail.com> wrote:

> On Thu, Dec 30, 2010 at 9:24 AM, bearophile <bearophileHUGS at lycos.com>wrote:
> 
> > Jonathan M Davis:
> >
> > > typedef is definitely on the way out, so that's not a solution,
> >
> > typedef is deprecated (because its semantics is not flexible enough and
> > because it doesn't play well with object oriented language features), but I
> > have a real need for something like it. Andrei has discussed about a
> > Phobos-based typedef replacement (based on structs + alias this), but
> > nothing concrete has come out yet. I hope to see something to solve problems
> > like spir ones.
> >
> >
> > > and it would be a pretty fragile one IMHO anyway.
> >
> > Please, explain better.
> >
> > Bye,
> > bearophile
> >
> 
> As far as I know, typedef was a form of "discriminated alias". I don't know
> the reasons for its deprecation. It just occurred to me that D's typedefs +
> templates could be quite handy in this case.
> 
> Consider:
> 
> struct semantic_wrapper(T)
> {
>     this(T value) { this.value = value; }
> 
>     T value;
> }
> 
> typedef semantic_wrapper!(int) Position;
> typedef semantic_wrapper!(size_t) Count;
> typedef semantic_wrapper!(string) Filename;
> typedef semantic_wrapper!(string) DirPath;
> 
> void func(Position pos) { ... }
> void func(Count c) { ... }
> void func(Filename fname) { ... }
> void func(DirPath dir) { ... }
> 
> void main()
> {
>     func(Position(1)); // calls first overload
>     func(Count(5)); // calls second
>     func(Filename("file.txt")); // third
>     func(DirPath("/dev/null")); // fourth
> 
>     func(1); // fails
>     func("blah"); // fails
> }
> 
> 
> Requires a little more typing, but sometimes it can be better than creating
> a new function name (which can get extra-big, non-telling or both) or than
> creating factory methods (which I personally dislike, although it's just a
> matter of taste most of the time; sometimes you may want to instantiate from
> inside a template and classes needing factories would not work, for example,
> but one could argue on the validity of this anytime).
> 
> Just giving my 2 cents. Dunno if I missed some detail.

I would have several needs for wrapper structs or classes like yours.

I like very much your proper use of proper terms (here type names): I myself make a difference between machine types and conceptual types. For instance, I always define:
    // standard type aliases
    alias sizediff_t Ordinal;   // index, which one
    alias size_t Cardinal;      // count, how many
and use exclusively Ordinal and Cardinal in code. But this would be better with a discriminating instruction. the issue, then, is with literals:
* Either such types must be defined by the language, and literals are properly cast (like in the case of int vs uint vs dchar for instance).
* Or literal casting works even with discriminating/exclusive types (which don't mutually cast); meaning eg a string literal would be accepted where a Name is expected even if string's do not cast to Name's.

What do you think of the points I mention in favor of a "discriminating alias" in a // post?

Denis
-- -- -- -- -- -- --
vit esse estrany ☣

spir.wikidot.com



More information about the Digitalmars-d-learn mailing list