>>I would say traits are type properties I like your description :)
###### Let me use some pseudo code to illustrate a kind of support for traits that can be quickly implemented for ATS3. Say we have a template: #extern fun <a:type> foo(x: a): void And we have two different implementations for foo: impltmp {a} foo(x) = (* first *) impltmp <a> foo(x) = (* second *) Now we have two instances of foo in our code: val () = foo<int>(100) val () = foo<string>("100") Say that the first instance should use the first implementation of foo and the second instance should use the second implementation of foo. To achieve this, we could introduce a trait called FOO2 for the second implementation: impltmp <a> FOO2(a) => foo(x) = (* second *) // the pseudo syntax means that this implementation is guarded by FOO2(a) Let FOO2 be given the following implementations: impltmp {a:type} FOO2<a> = true impltmp FOO2<int> = false To compile the instance foo<int>, the second implementation is first picked; but the guard FOO2<int> is false; so this implementation is skipped and the first implementation is picked next. ###### Using traits for constructing guards is a low-hanging fruit. We could certainly think of ways for traits to be used to guide template resolution in a more profound manner. --Hongwei On Friday, July 3, 2020 at 4:29:29 PM UTC-4, Matthias Wolff wrote: > > C++ Term Traits: > > I would say traits are type properties > > struct oracle; > > struct postgres; > > template<typename T> > void print_database(T t /* value only for type deduction -- avoiding > explicit <>*/) > { > /*Type resolution: database is unknown at this stage, database is a > dependend type, but type dependend */ > > if constexpr (is_same<typename T::database,oracle>::value) { cout << > "oracle" << endl; return; } > > else if constexpr (is_same<typename T::database,postgres>::value) { > cout << "postgres" << endl; return;} > > else { static_assert("Unsupported type"); } > } > > struct abc > { > }; > > struct def > { > }; > > template<typename T> > struct db_traits; > > template<> > struct db_traits<abc> > { > using database = oracle; > }; > > template<> > struct db_traits<def> > { > using database = postgres; > }; > > template<typename T> > struct something > { > using database = typename T::database; > }; > > int main() > { > something<abc> s; > > print_database(s); > > return 0; > > } > > Typetraits are lightweight information because the implementations of the > types/structs/classes > are not of interest. Types are only names in this context. > > Remark: Generic programming is like any abstraction if only one example is > available. > It makes things more complicated. But looking on universal properties it's > clear it needs > a bunch of examples to get a benefit. So many developers can live without > it. But everyone > will try it - the "feature" effect. > > C++ term concepts: > > It's relatively new, available since C++-20. It an improvement in the area > specification of > templated constructions. Typically, in the C++ world it's forbidden to use > a mathematical > vocabulary. Make better specifications seems to be the goal. I have no > personal experiences. > > Remark2: C++ concepts is an additional feature but not a concept. The > world of C++ scientists > is restricted by C++. It's more a (distinct) feeling: replace concepts by > ats-proofing. > > Be sure, other c++ developers will tell you other things. > Am 03.07.20 um 20:10 schrieb gmhwxi: > > > Traits: > > Based on my understanding, traits in C++ can be implemented in a more or > less > straightforward manner. To me, traits are an template-based approach for > generating > ifdef-guards used in C. > > However, I would prefer to take a deeper look at the template resolution > algorithm. Traits are > a bit like band-aid used at surface. One can expect to achieve a lot more > if there is a logical way > to affect the manner in which template code is replaced with non-template > code. > > Concepts: > > It is a feature mainly for statically debugging templates. I am looking > into it. Debugging templates > statically is a big thing; I prefer something with clearer semantics. > Let's wait and see. > > -- > You received this message because you are subscribed to the Google Groups > "ats-lang-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to ats-lang-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/ats-lang-users/337ff3b2-40ed-43cc-9e0f-d62cfa6e4a42o%40googlegroups.com > > <https://groups.google.com/d/msgid/ats-lang-users/337ff3b2-40ed-43cc-9e0f-d62cfa6e4a42o%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > -- You received this message because you are subscribed to the Google Groups "ats-lang-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to ats-lang-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/556bda1e-a680-4a87-aeb4-7b023c8d9714o%40googlegroups.com.