On Monday, 4 January 2016 at 00:49:29 UTC, Andrei Alexandrescu
wrote:
Second, ET as a mechanism for SQL interface has other inherent
limitations. Consider the "LIKE" operator in SQL, which has no
ET equivalent in C++ with similar syntax, and no direct
like(Person.Name,"peter%")
Person.Name == pattern("peter%")
On another example, C++'s overloading of &&, ||, and the comma
operator are considered downright disastrous and are
unrecommended by virtually all coding standards and guidelines,
Guideline means that you should think hard about it before you do
break it. A guidelines does not mean that you never should do it.
It means you should only break the guideline when you have good
reasons to do so.
If you can overload "and" and "or", you also can implement
ternary logic, fuzzy logic and other logics. In some cases that
is desirable.
In C++ features were abused when they were new because people
were eager to stretch new features to the limits. This is not a
problem in regular C++ programs. And in the case of C++
iostreams, it has become an idiom that isn't causing any
problems. C++ programmers are never confused by shift and output
operators.
But if this is a big deal the easy solution is to add unicode
operators without default behaviour.
String processing is not an acceptable alternative, it ruins
tooling. You should essentially never be able to turn a symbol
into a string and vice versa. D unfortunately allows you to do
it. That is a mal-feature aka a textual macro feature.
You can't really say that D has gotten rid of macros when you
actually encourage using macro-like textual substitution features
in place of processing proper symbols. That is an outdated 70s
paradigm.
