Overloading relational operators separately; thoughts?

[Jacob Carlborg via Digitalmars-d]

On 2016-09-29 09:58, Walter Bright wrote:

> I.e. you can overload '+' to do bad things. Yes, you can, and as I
> replied upthread that can be done because there's no way to prevent that
> while having operator overloading at all.
>
> But that is not justification for allowing such disasters for the
> comparison operators. I.e. one weakness is not justification for opening
> the door to all weakness.

You're using the same justification when rejecting most feature requests 
you don't like: you had one bad experience with C++ and therefore it 
must be banned for all eternity. It's not a valid argument.

> Interestingly, by shutting the door on misuse of the comparison
> operators, it seems D has been successful in discouraging nutburger
> designs like overloading '+' to mean 'OR'.

It's also shutting the door on doing a lot of useful things. My goal is 
no to use the comparison operators to mean something different than 
comparison. The goal is, for example, to build a corresponding SQL query 
out of an expression. But the == operator would still be used for equality.

One major issue with using string literals is, if we use the SQL query 
as an example again, as follows:

First try:

auto bar = `"bar"`;
auto query = "SELECT * FROM foo WHERE bar = " ~ bar;

Is have the issue of SQL injection.

Second try:

auto bar = "bar";
auto foo = "foo";
auto q = query("SELECT * FROM foo WHERE bar = $1 AND foo = $2", bar, foo);

This has the issue that the value and the place of where a value is used 
far away from each other in the code making it more difficult to read. 
This was "solved" in Rails by using an associative array mapping the 
column names to the values:

foo = "foo"
bar = "bar"
Foo.where(bar: bar, foo: foo)

That has the issue of only working with equality and "AND". Now way to 
do less than or "OR".

Third try:

auto foo = "foo";
auto bar = "bar";
Foo.where(q => q.foo == foo && q.bar == "bar");

The above expression would be translated to the query in the second 
example, with the values properly escaped. Now this is how I want the 
code to look like.

>> The language you just provide a set of tools, then it's up the to the
>> programmer
>> to do what he/she wants to do.
>
> That can be used to justify any feature at all.

> I know you really want AST macros for D. We've discussed that at length
> before.
>
> BTW, there's a CTFE parser generator for D around somewhere.

And that will handle all that the DMD parser does? I don't think so.

-- 
/Jacob Carlborg