On Wed, Jun 13, 2018 at 2:15 AM, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Mikhail V wrote:
My feeling is that inserting is not a frequent enough operation to warrant having its own operator, especially not when there is already a syntax that does the same thing.
Depends on what you count as 'insert' - append is one case of insert ;) (logically seen) Sorry for repeating myself, the idea was that the default meaning is append(), i.e. normal operator usage on list: L1 = L2 ^ item - would be same as L1 = L2.append(item) But hope you get the point - if an operator for append was added, then it would be a bit sad that it cannot be used for inserting by slicing, namely these two forms: L ^= item #append(item) L[i:j] ^= item #insert(i, item) instead of i:j items would be IMO nice to have and it 'd cover both insert and append. But if you say that special-casing of [i:j] here would be hard to implement, then maybe insert() idea should be dropped.
That would raise the question of why ^= is getting this special treatment but not any of the other augmented assignments, and why not "in-place operation with attribute" as well
As said, I don't insist on ^ operator. I would find ">>" or "<<" or "|" ok as well: L <<= "foo" L1 = L2 << "foo" L |= "foo" L1 = L2 | "foo" But it would raise same questions. As for relation 'by sense', that may be too opinion based. Vertical bar "|" may be somewhat related - IIRC in some contexts it is used as element separator. Just hope the judgement is not like "the symbol looks strange - therefore the feature is not needed". M