Compact should not be bundled with sort. Sometimes you only want one.

I've changed the proposal to use Compact and CompactFunc.

not to bikeshed, but I think rust had a good idea with dedupe: #47203 (reply in thread)

@colin-sitehost dedup was suggested before Russ called off the bike-shedding. There's also a bunch of specific replies to that suggestion in-between the two comments. Basically "Dedupe has exactly the same problems Uniq has, there is no indication that it only removes successive duplicates".

Resolved as Compact. Part of the point of using Compact is that it's not in other language's APIs, so we get to define the word without preexisting connotations.

Consistency within Go, vs. occasional consistency with Rust seems the better way to go? So if Grow() is used elsewhere for similar purposes in Go, and Go has yet(?) to use Reserve() for similar purposes then Grow() would seem preferable, at least to me. #fwiw

I never said we should choose names to be consistent with Rust, just that I think Reserve is a strictly better name for this function.

I don't like the name Grow for this function, since it doesn't actually Grow the slice by the amount specified. A developer reads the word "Grow" and they think they know what is happening, but that isn't what is happening. However, using the name Grow to be consistent with prior implementations in Go is probably the right choice, which was my conclusion.

FWIW I also think Reserve is a better name and I think consistency like this is broken in a couple of places already¹. I'm not sure I feel that *bytes.Buffer.Grow is a prominent enough precedent to justify choosing the worse name. I could go either way on this.

[1] For example, I regularly want to call *bufio.Scanner.Scan() as Next().

I have no strong feelings about the name Grow vs Reserve, but I do think Unreserve is useful, and I’m not sure of another good name for it. Maybe LimitGrowth?

Resolved as Grow(n) in latest API. Unreserve/Shrink is Clip.

Frankly I like upsetting Hacker News commenters.

More serious comment: having an easy to use Clone and a Grow function for setting capacity makes Map less useful. I do sort of want a better Filter though because the current idioms are a bit verbose and there are more than one way to do it.

yeah, I would much rather see a "proper iterator system", and I assume that would be a thing to investigate once we see how generics land?

Like @DeedleFake I agree that these fumctions should not be added at all, but not because they are functional. In the long run, I think Go will benefit from an official package like Java's streams or C# LINQ. How such a package evolves is another discussion altogether. Perhaps a community package will arise that's good and stable, or one can be created in /x where it can marinate for a bit and mature.

Removed Map/Filter/Reduce from latest API.

s[:len(s):len(s)] is clear, really very easy to type, and hard to get wrong.

That's true, but less true as the variable name gets even marginally longer (because the expression increases at 3x the rate of the name).

It is of course possible to factor out a variable, but then you have to pick another (short, unused) variable name, which can add a lot of cognitive overhead in and of itself.

To use some real examples:

Today, with a per-package copy of this function:

As an explicit expression:

		rootModules: rootModules[:len(rootModules):len(rootModules)],

(I find that one frankly hard to even parse.)

As slices.Shrink:

		rootModules: slices.Shrink(rootModules),

Today:

Expression:

	mg.buildListOnce.Do(func() {
		bl := mg.g.BuildList()
		mg.buildList = capVersionSlice(bl[:len(bl):len(bl)])
	})

slices.Shrink:

	mg.buildListOnce.Do(func() {
		mg.buildList = slices.Shrink(mg.g.BuildList())
	})

It can always be added later if we can make the case that it's very important.

That's true, but putting it off makes #38081 (comment) feel like a bit of a bait-and-switch. 😒

"We should wait for generics before deciding to make it a language change" and
"we should wait for generics to settle more before deciding this is important enough to put in package slices"
can both be true.
It's not really a bait-and-switch, just taking new APIs slowly.

This was on the wrong thread: #47203 (reply in thread)

I’m happy with the pair of names Grow([]T, int) and Shrink([]T).

I feel like I don’t know if I would use Map or not, but I’m 100% sure I’d use Grow and Shrink if they existed.

Talked to @ianlancetaylor who had a strong reaction against Shrink. We ended up with Clip instead, although "Pollard" was a fascinating alternative.

yeah, sorry for the double post; but the Any caught me off guard too

I agree, but personally think that's a reason to have neither.

Fine with me too. For some reason I think Index is harder to screw up than is Any/Contains vs. All/ContainsOnly.

I'm tempted to publish a package called truthy with Any/All funcs and maybe some sort of First function so you could write if truthy.Any(myStrings) { return truthy.First(myStrings) } etc. ISTM that Any/All don't really need to be in the slices package per se, and in languages like Python/JavaScript any and all benefit greatly from a concept of truthiness.

FWIW @carlmjohnson if you write if Any { return First } then you end up doing 2X the work you really need.

Resolved to leave these out. We already have IndexFunc. We dropped ContainsFunc as not common enough, but it can always be added later.

If this is unacceptable, I think we must use two Ts:

// ContainsFunc is like Contains, but it uses a comparison function.
func ContainsFunc[T1,T2 any](s []T1, v T2, cmp func(T1, T2) bool) bool

Since being able to express this is also important:

ok := slices.ContainsFunc([]string{"one", "two"}, 'o', strings.ContainsRune)

And yeah, we can still do this pretty well:

ok := slices.ContainsFunc([]time.Time{time.Now()} time.Unix(1626299610), time.Time.Equals)

EDIT: though as @Merovius called out, this is nearly impossible to express clearly:

ok := slices.ContainsFunc([]time.Time{time.Now()}, struct{}, func(t time.Time, _ struct{}) bool { return t.IsZero() } )

ok := slices.ContainsFunc([]string{"one", "two"}, 'o', strings.ContainsRune)

What if the arguments in ContainsRune where swapped? You'd still need a closure. I'm not sure why we should assume that the order of arguments for the comparison-function is the one that is beneficial for this form of ContainsFunc, for the operations people want to use it.

And yeah, we can still do this pretty well:

Yes, but you are basing that argument on an actual equality function. The argument is that it's easy to express a boolean predicate using an equality-function (and even easier using a method, as you demonstrate), but hard to do it the other way around.

Try using something like time.Time.IsZero instead.

agreed, I strongly prefer the predicate form that matches IndexFunc, but if that is unacceptable for some reason, I think we must not require a single T any for both the s and v. sorry to muddy the waters.

EDIT: after working through an example, if we have T1,T2, you can use struct{} to obviate which parameter is ignored, but yeah it is not good.

We resolved this by deleting ContainsFunc at least for now. I agree with you that it should match IndexFunc, but it probably doesn't provide enough beyond IndexFunc to add. We can always add it later.

FWIW, IMO consistency with other languages is a low priority. Sure, if we have multiple good options for names, might as well choose the more common one. But if we think a name is better, "other languages are using a different one" shouldn't dissuade us.

PartialOrd not Compare (and language primitive not func)

Compare imposes a total order, so this seems wrong. (Also, is PartialOrd a language primitive? Isn't it a trait?)

Index is implemented as binary_search

That's not the same function then. It's strictly less powerful, as it makes strictly more assumptions about the input.

FWIW, IMO consistency with other languages is a low priority. Sure, if we have multiple good options for names, might as well choose the more common one. But if we think a name is better, "other languages are using a different one" shouldn't dissuade us.

yep, just calling out differences as a summary; no pressure to change anything. (well maybe dedupe)

Compare imposes a total order, so this seems wrong. (Also, is PartialOrd a language primitive? Isn't it a trait?)

I am simplifying things, but yeah; and i think std::cmp::Ord is what i should have said.

That's not the same function then. It's strictly less powerful, as it makes strictly more assumptions about the input.

fair, feel free to leave it off; it felt like it met the spirit, but there is probably something in std::iter::Iterator that fits better.

I think the main input of other languages is if N languages use some name for some function, if Go uses the same name it should be equivalent, not different, because it causes confusion. So “Uniq” is not great because it might mean compact or it might mean toSet.

The other thing to take away from other languages are that people like/use these functions, but I suppose they can be saved for 1.19+.

FWIW, Index/IndexFunc is not binary search.

This has been proposed under the name Clone. strings/bytes.Clone is coming in 1.17, so it’s a pretty sure bet for slices too.

Thanks, I had missed that.

Looks like #45038 was indeed accepted, but never implemented, so I guess it will be in 1.18.

I forgot to bring this up at the proposal review but I have it noted for next week.

Given that we will soon have strings.Clone and bytes.Clone, I am also in favor of

// Clone returns a shallow copy of s.
func Clone[T any](s []T) []T

Resolved by adding Clone.

Is Reduce still in the proposal? That definitely shouldn’t be in the 1.18 standard library. :-P

I've already commented multiple times that this is the approach - just the parts that clearly belong because they are obviously the right API and have widespread applicability. We are not going to make an x/exp/slices though. Other people can experiment with APIs in their own libraries.

Resolved: we agree.

I also think this is probably below the bar because while obviously, I use strings.Join all the time, I can't think of the last time I needed a non-string/bytes join. I think if we didn't have Insert and Delete, you could just have Concat and tell people to use that instead, but this doesn't seem to be a popular idea.

But maybe @go101 wants to argue for Concat, on the grounds that it could use some unsafe trickery to be faster than manually appending.

I see uses of append that inappropriately reuse the target slice semi-regularly, along the lines of:

return SomeType{
  A: append(s, v1...),
  B: append(s, v2...),
}

While this isn't difficult to write correctly, a slices.Concat that creates a new slice would be useful for this case.

The bug could also be addressed with:

return SomeType{
  A: append(slices.Clip(s), v1...),
  B: append(slices.Clip(s), v2...),
}

😄

Well, not quite. If v1 or v2 might be empty, then A and B might still alias s (or each other), which may not be what is intended.

Resolved: decided not to add Concat in the initial set. We can always reconsider if there is significant evidence.

You can hide a comment (or the whole thread? haven't tried it) with the reason being "Resolved".

Edit: It just hides that comment, not the thread underneath, so maybe it's not that useful. Shame.

I mean, you could want something or implement something "more sophisticated", but if all you are asking for is yes/no Contains or Index as it is defined in bytes, strings, and the draft proposal, it should just be a linear order search.

I don't like the varargs form - to me, that strongly suggests ContainsAny semantics, not searching for a sequence of elements.
I agree that wrapping a single element is inconvenient, though. But maybe that just means we should have separate functions.

strings.Index and bytes.Index switch to internal/bytealg.IndexRabinKarp when the slice and subslice lengths are longer than some system specific MaxLen. I don't see why that same logic wouldn't apply to slices in general.

General arrays and strings are different things.
You are almost always looking for one element of an array, not a subsequence.
The subsequence is too much complexity for not enough benefit.

Resolved: decided not to add sequence operations here, leaving API about elements.

@mikeschinkel You are correct that I was just stating opinions, not providing evidence or proof. That's, as far as I'm concerned, all we can do here - though I would certainly accept evidence or proof that what I say is wrong. Meanwhile, I don't think being an opinion disqualifies my comments or that it's reasonable to dismiss them on purely formal grounds (i.e. calling every sentence of it a fallacy), instead of taking its content into consideration.

You are also correct that I phrase my opinion as absolute statements. I do that, to emphasize that my opinion is that there really are things which are not in any sort of gray area and that my opinion is, that the functions in this proposal are such things. That is, I'm trying to say "I have an opinion about something being absolute", not "my opinion is absolute truth". It's a subtle difference and I apologize for not making it more clear.

I don't really know how to address the rest of your response, except as by pointing out that there is also a fallacy fallacy: Assuming that because someone commits a logical fallacy, they must be wrong. Saying someone commits a logical fallacy is not, in itself, an argument that they are wrong.

Apart from that, I tried to explain why I think panicing is appropriate above and I'll just leave the thread at this point.

@Merovius — 

"I don't really know how to address the rest of your response, except as by pointing out that there is also a fallacy fallacy: Assuming that because someone commits a logical fallacy, they must be wrong.""

I was not necessarily stating that you were wrong in specific cases, instead I was calling out your frequent use of fallacious arguments in reply to me as well as many others. I wouldn't have called it out except that you repeatedly misrepresented my argument about Go being pragmatic.

That said, @ianlancetaylor had a good point in his comment just before your most recent reply.

Resolved: panics are OK where the analogous language operations would panic.

I guess I will agree to disagree. I don't believe the underlying language should panic either, actually. If it has a trustable length, then it should use it to avoid panics that may have an immeasurable detrimental affect.

This is open source. We can always make a non panicking version of this package once it is done.

• proposal: container/set: new package to provide a generic set type (discussion) #47331
• proposal: maps: new package to provide generic map functions (discussion) #47330

Yes, we should be able to do it in either order.

I don't know that the Slice constraint should be part of the exported API of this package.

constraints.Slice[T]

Accidentally created a new comment thread for constraints.Slice[T], although perhaps that's for the best: #47203 (comment).

(The two reply boxes are right next to each other!)

Constraint type inference does work on the playground, but the implementation there hasn't changed for 1/2 year or so. So one has to use the old syntax and perhaps not all refinements are available.

Still this specific example of a possible Insert actually works and does what is expected.

(Sometimes it times out, but every once in a while it makes it through.)

Resolved: yes, we will add support for named slice operations.
Also tentatively adding constraints.Slice to the constraints proposal.
It is true that we can write interface{~[]Elem} instead of constraints.Slice[Elem],
but the latter may be much readable for consumers of APIs
(reading the type signature to understand the function -
consumers of generic code, not authors of generic code).

What about func Insert[Slice ~[]Elem, Elem any](s Slice, i int, v ...Elem) Slice? Concise and clear.

You still need an interface, though:

func Insert[Slice interface{~[]Elem}, Elem any](s Slice, i int, v ...Elem) Slice

(https://go2goplay.golang.org/p/_DGAo_m5sh5)

(Maybe at some point in the future we can show that ~[]Elem is equivalent to interface{~[]Elem} but we're not there yet (and won't be for Go 1.18).

You still need an interface, though. Maybe at some point in the future we can show that ~[]Elem is equivalent to interface{~[]Elem} but we're not there yet (and won't be for Go 1.18).

I'm curious what you see as the barrier exactly? Is it conceptual, lack of formal proof, implementation work?

I'm trying to think how, in the context of type parameters, ~T is not equivalent to interface{ ~T } but I'm drawing a blank.

It should be true that type parameter T always has the same type set (as per #45346) as interface{ T }. For example the type set of int and interface{ int } are the same, just like fmt.Stringer and interface{ fmt.Stringer }.

Print[T fmt.Stringer](t T)              // Legal.
Print[T interface{ fmt.Stringer }](t T) // Legal, unnecessary.
Print[T interface{ int }](t T)          // Legal, but silly.
Print[T int](t T)                       // Not legal.  Also, silly.
Print[T interface{ ~int }](t T)         // Legal.
Print[T ~int](t T)                      // Not legal, but why shouldn't it be?

Why should I be able to use interface{ int } as a meta type, but not ~int? The former is nonsensical, the latter is useful. Perhaps instead of "meta types must be interfaces", we can adopt "meta types must have a type set comprising more than one type". I'd rather the compiler errored because "interface{ int } matches a single type" rather than "approximation element ~int is not allowed outside an interface".

We've considered the possible equivalence of interface{~T} and ~T when working on the type set approach. The "obvious" difference at the moment is that T and A | B (for types) is simply not syntactically permitted outside an interface.

But there's a more subtle issue. One of the goals of the type set approach is that eventually we might be able to use "constraint" interfaces as ordinary (non-constraint) types; as in: var x interface{~int}. If that were permitted, there seems to be a difference between var x interface{~int} and var x ~int: For the former, the zero value would be nil (that's the zero values for interfaces), but for the latter it probably should be 0. (This is even more obvious when choosing the non-sensical interface{int} type.)

For constraints, the interface zero value doesn't matter - a type parameter is not an interface, the interface is simply describing the properties of the type parameter. So perhaps one should be able to just write [T ~int] - it certainly would be nice. But for now we decided to err on the side of caution and stick with always requiring an interface, albeit with the extended mechanism for embedding of elements.

But let's keep discussing this elsewhere, it's not directly related to the slices proposal. Thanks.

Resolved: will add constraints.Slice to the constraints proposal.