Feature request: Path append operators for strings

[Wyatt]

On Wednesday, 3 July 2013 at 12:24:33 UTC, Wyatt wrote:
> This is something I was discussing with a friend recently, and 
> we agreed it would be cool if there were set of operators with 
> no definition until overloaded, so you could use e.g. (.) for 
> dot product, (*) for cross product, (+) (or maybe [+]?) for 
> matrix add, etc. instead of overloading things that already 
> have specific, well-understood meaning.
>
I'd like to clarify this a little with a concrete example I hit 
late yesterday.  I have a sparse tree-like recursive struct with 
an array of children and a single leaf value.  I thought it was 
fairly simple, but I quickly found the range of common operations 
I want to support exceeds the limits of orthogonal operations.

Like my opOpAssign!("~") adds the children of the RHS as children 
of LHS, while the opIndexAssign assigns a leaf value to a child 
of LHS, and the opIndexOpAssign!("~") makes the entire RHS tree a 
child of the LHS.  And I'm sure I'm not "done"; but I'm also VERY 
reluctant to go any further because it's getting ugly fast. (I 
think I may be able to _somewhat_ work around this with multiple 
overloads for different types. I haven't tried it, but I think 
that works?)

Having some way of differentiating the different semantic 
concepts (i.e. operating on trees vs. operating on leaf values) 
would be hugely useful for my ability to reason about the code 
easily.  Not just that, having a way of offsetting them 
_visually_ would be useful for me to keep track of them and know, 
at-a-glance, that I'm doing something different; something that's 
not QUITE like e.g. a concatenation. (As I think I mentioned, I 
see this as a major factor in favour of some kind of bracing, if 
not parentheses.)

IMO, it's the sort of thing where almost any non-trivial data 
structure you manipulate frequently could stand to benefit.  
Unfortunately; conversely, I _also_ completely understand that 
adding more features to the language at this point is a fairly 
tall order.  Worse, I think this would require some compiler/spec 
changes.  Or maybe there's a third path I'm not seeing-- I don't 
know.

All that said, does anyone aside from myself and a few others 
have strong opinions on this?

-Wyatt