Regardless of its merits, the language is basically frozen at this time. Most proposals are around standard library modifications, and even then most are rejected because the standard library is also pretty frozen. The bar for language changes is high and must be supported with lots of data to support a proposal. Do you have data to support that a significant percentage of append usage is for non-append use cases?

Do you have data to support that a significant percentage of append usage is for non-append use cases?

I doubt that's true. What's true is that append is currently the only sane way of removing elements from a slice, or inserting elements at an arbitrary position.

Is splicing really that common of a task? There are use-cases, but is it a day-to-day need for the average programmer working on an "average" project? Even then, is it the only solution? Splicing usually implies that the order of elements in a slice matters, thus use of the "sort" package may be an alternative to many of these needs.

Regarding the specifically proposed function signature: I'd argue that Go tends toward "i:j" semantics rather than "i:length" semantics. deleteCount is similar to "length" in this case, rather than establishing a "replacement window" that, I at least, would expect.

I don't want to add more builtin functions.

There is a way to add these without builtins. We all know it's name. But it
is gorbidden word around here.

2016 rugp. 1 03:49 "Rob Pike" notifications@github.com rašė:

I don't want to add more builtin functions.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#14991 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ADWPFRzEqKfZyziB9oQfkhu1U3wanpWLks5qbUKSgaJpZM4H5vZw
.

Closing. The language is frozen.