[Generics] Constraints package name

[freder...@gmail.com]

The package name "constraints" is quite a mouthful to read:

  func Min[Elem constraints.Ordered](s []Elem) Elem {}

Did you consider other package names like "is"?

  func Min[Elem is.Ordered](s []Elem) Elem {}

is.Ordered

is.Integer

is.Signed

is.Unsigned

[Jesper Louis Andersen]

On Sun, Jul 26, 2020 at 9:30 AM <freder...@gmail.com> wrote:

The package name "constraints" is quite a mouthful to read:

  func Min[Elem constraints.Ordered](s []Elem) Elem {}

Did you consider other package names like "is"?

  func Min[Elem is.Ordered](s []Elem) Elem {}

You can always solve that with a rename:

import (

  is "constraints"

)

but you run the risk of users not knowing what the "is" package is. Also, the name "is" doesn't follow the usual naming style of Go packages. I tend to find such package names risky because they don't really say what they contain. This means they become attractors of all kinds of different functionality over time, where most of that functionality isn't belonging in there but in separate packages. It is like declaring a package such as "util", "misc", or "aux".

--

J.

[freder...@gmail.com]

On Sunday, July 26, 2020 at 12:46:38 PM UTC+2, Jesper Louis Andersen wrote:

You can always solve that with a rename:

import (

  is "constraints"

)

but you run the risk of users not knowing what the "is" package is.

Of course, but like you said, "is" would be unfamiliar to most other users. People usually use the default package name and that's what we will have to read the most.

 

Also, the name "is" doesn't follow the usual naming style of Go packages.

I'm not sure if there is a Go standard library package naming style other than "relatively short name". 

 

I tend to find such package names risky because they don't really say what they contain. 

The package doc comment can say that it contains constraints.

 

This means they become attractors of all kinds of different functionality over time, where most of that functionality isn't belonging in there but in separate packages. It is like declaring a package such as "util", "misc", or "aux".

I'd trust the Go maintainers that they can resist to clutter it with unrelated things.

[Robert Engels]

I like ‘is’. Very readable and Go-like. 

On Jul 26, 2020, at 6:05 AM, freder...@gmail.com wrote:



--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/f623ffc6-757c-44a7-bbcf-0e8b59efa714o%40googlegroups.com.

[Axel Wagner]

On Sun, Jul 26, 2020 at 1:05 PM <freder...@gmail.com> wrote:

Also, the name "is" doesn't follow the usual naming style of Go packages.

I'm not sure if there is a Go standard library package naming style other than "relatively short name". 

"relatively short name" is less consistently applied than "be descriptive of what's in there". Without the context of generics, what would you think is in "is"? What's in "constraints"? What's in "quotedprintable"?

 

 

I tend to find such package names risky because they don't really say what they contain. 

The package doc comment can say that it contains constraints.

 

This means they become attractors of all kinds of different functionality over time, where most of that functionality isn't belonging in there but in separate packages. It is like declaring a package such as "util", "misc", or "aux".

I'd trust the Go maintainers that they can resist to clutter it with unrelated things.

--

[Andrei Tudor Călin]

The entire notion of the constraints package feels a little suspicious to me. What if the comparable and ordered constraints were pre-declared in the universe block, and the numeric constraint were named math.Numeric? What other universal (or close to universal) constraints would belong in this entirely agnostic "constraints" package?

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/fb694112-7d2f-4db0-a0fd-86fd05459ae3o%40googlegroups.com.

--

Andrei Călin

[Frederik Zipp]

ma...@acln.ro schrieb am Montag, 27. Juli 2020 um 08:34:04 UTC+2:

The entire notion of the constraints package feels a little suspicious to me. What if the comparable and ordered constraints were pre-declared in the universe block, and the numeric constraint were named math.Numeric?

In this case 'Ordered' might belong in the "sort" package: sort.Ordered, and most other constraints in the 'math' package: math.Numeric, math.Complex, math.Unsigned. Or maybe 'Complex' belongs in "math/cmplx" as cmplx.Number.

But from a dependency hygiene perspective it is probably better to have the most common constraints in a dedicated package rather than distribute them over existing packages. I suppose we would not want "math" to import "sort" in order to implement Min and Max.