On Thu, 30 Dec 2010 10:07:58 -0200 Guilherme Vieira <[email protected]> wrote:
> On Thu, Dec 30, 2010 at 9:24 AM, bearophile <[email protected]>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
