For && and || I disagree: they are 'shortcircuiting' operators and as such they deserve a différent name than just 'and', 'or'. That said &| should have been named and,or which would have freed &| to use for the shortcircuit operators.

> The cost of dead people is a lot higher than the cost of developer time.

So you're using proof on every line of code you produce?

> So you're using proof on every line of code you produce?

No, except for trivially (the code is statically and strongly typed, which is a proof mechanism). The set of activities chosen to give confidence in defect rate is varied, but only a few of them would fit either a traditional or formal verification definition of a proof. See DO-178C for more.

Once Claude found a bug in my code but I had to explain the structure of the data. Then and only then it found the bug.

Error safe, the : or :: I kind of doubt it, I think that finding a typing mistake (two : instead of 1) won't be easy..

Your point is funny but if you're not anal-retentive about the syntax you get monstrosity such as the CSV-escape rule instead of the passwd-escape rule..

> Dual use means extra ceremony with escaping

It depends, if you allow nesting you also need escaping.

Escaping of what?

Of 'yourself', if a text field contain embedded/nested text you need to escape the delimiter.

This case is much rarer than escaping quotes or whitespace. It will happen only if the content of the block will contain unsanitized inputs. In such case a control character for escaping will help, or, if you can have 2x range for control characters, you can use one bit for escaping. E.g. 0x1-0x7 - delimiters, 0x8-0xF - escaped delimiters.

I wonder if it wouldn't be better to have two fans: one at a high position and one at a low position.

> you can't have practical automobiles without inventing the windshield wiper

Sure, but remember that some wipers were "hand activated".

D (as always) is clever: the operator is ~ So no confusion between addition and concatenation and you can keep | for or.

Question, does that work with other types? Say you have two u16 values, can you concatenate them together with ~ into a u32 without any shifting?

It works with arrays (both fixed size, and dynamically sized) and arrays; between arrays and elements; but not between two scalar types that don't overload opBinary!"~", so no it won't work between two `ushorts` to produce a `uint`

No, it doesn't. But I'm not sure that this matter, a sufficiently "smart" compiler understand that this is the same thing.

Next time can you to do Python's string interpolation? ;-) It's much more pleasant to read (when properly used).