On Wednesday, 28 September 2016 at 03:12:05 UTC, Jonathan M Davis
wrote:
On Wednesday, September 28, 2016 01:18:58 Minty Fresh via
Digitalmars-d wrote:
Basically, having them be overloaded separately is error-prone,
and it leads to folks overloading them in ways that have
nothing to do with what they mean for the built-in types, which
makes code harder to read and maintain. D has a concatenation
operator specifically because Walter thought that it was
horrible to use + for concatenation.
If you want to write DSLs, then use strings and mixins. D gives
you a _lot_ of power in that area, and it avoids the problems
associated with making overloaded operators do things other
than what those operators are normally intended to do. With
strings, you can make your DSL look however you want - even
doing stuff like using various Unicode symbols as operators if
you want to. Even with how C++ overloads operators, overloading
operators gives you fairly limited options with what you can do
with a DSL, whereas you have full freedom with strings - and
without the problems that come with trying to make your DSL
look like normal D code.
- Jonathan M Davis
Using strings and mixins does have quite a number of downsides.
The additional work required to past the DSL aside, you also
usually lose the scope in which things are declared (especially
if you wish to reference or declare variables/functions/other
constructs within your DSL), error reporting becomes much less
precise, and the transition between the outer code and the inner
DSL becomes jarring (especially in terms of syntax highlighting).
That said, I love the fact D has a separate operator for
concatenation. It's extremely useful to not have that ambiguity.
Another thought is, operators not behaving as expected doesn't
strike me as a failure of the language, given the language
supports operator overloading. It's a failure in documentation to
explain what the operators are intended to do, or a failure in
implementation to behave as they should.
Lastly, if operators are intended to behave so strictly, why does
this not extend then to binary arithmetic operators (+, -, *, /,
%, etc.)
They don't follow the same rules as the binary relational
operators, after all.
