Proposal: Database Engine for D

[Ola Fosheim Grøstad via Digitalmars-d]

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.