Building C++ modules

[H. S. Teoh]

On Wed, Aug 14, 2019 at 11:51:55AM -0700, Walter Bright via Digitalmars-d wrote:
> On 8/13/2019 9:32 AM, H. S. Teoh wrote:
> > So you see, the seemingly insignificant choice of <> as template
> > argument list delimiters has far-reaching consequences.  In
> > retrospect, it was a bad design decision.
>
> There were some who warned about this from the beginning, but they
> were overruled. There was a prevailing attitude that implementation
> complexity was not relevant, only the user experience.

Having grown up in that era, I can sympathize with that attitude, but I
must say that given today's hindsight, citing user experience as the
reason for choosing <> as delimiters is very ironic indeed. :-D


> Another parsing problem exists in C as well:
> 
>   A * B;
> 
> Is that a declaration of B or is it a multiply expression? It cannot
> be determined until the compiler knows what A is, which requires
> semantic analysis.
> 
> You might think D has the same problem, but I added a simple rule to
> D:
> 
>   "If it can be parsed as a declaration, it's a declaration."
> 
> Which means A*B; is always a declaration, even if A is later
> determined to be a variable, in which case the compiler gives an
> error.
> 
> The reason this works is because A*B; is an expression with no effect,
> and hence people don't write such code. You might then think "what if
> * is an overloaded operator with side effects?" There's another rule
> for that, and that is overloading of arithmetic operators should be to
> implement arithmetic, which shouldn't have side effects.
> 
> (If you absolutely must have operator overloading, you can write
> (A*B); but such is strongly discouraged.)
> 
> The fact that in 20 years pretty much nobody has noticed that D
> operates this way is testament to it being the correct decision and it
> "just works".

Wow.  I never even noticed that, all this time! :-D

It also goes to strengthen the argument that operator overloading should
not be abused the way it has been in C++.  Choosing << and >> for I/O
seemed like a clever thing to do at the time, but it led to all sorts of
silliness like unexpected precedence and ambiguity with actual
arithmetic shift operations, necessitating the proliferation of
parentheses around I/O chains (which, arguably, defeats the aesthetics
of "<<" and ">>" in the first place).  And don't even mention that Boost
monstrosity that uses operator overloading for compile-time regexen.
Ick. The very thought makes me cringe.


T

-- 
Why can't you just be a nonconformist like everyone else? -- YHL