[go-nuts] Advancing the container/set design?

[Frederik Zipp]

Some time ago, Ian started a discussion about a potential proposal for a 
container/set package: https://github.com/golang/go/discussions/47331

The main point of uncertainty was iterating over elements. Now that 
iteration is solved in Go 1.23, is it perhaps time to advance this design 
and turn it into a proposal for the 1.24 release cycle?

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e52b942f-2642-483a-b451-14a25f422ea3n%40googlegroups.com.

[go-nuts] Re: [ANN] Interactive 2D graphics on an HTML canvas via WebSockets

[Frederik Zipp]

manlio@gmail.com schrieb am Sonntag, 4. April 2021 um 19:03:48 UTC+2:

> Thanks, it is really interesting.
>

Thanks.
 

> Do you know if there is a similar module that use the DOM API as target 
> instead of the Canvas API?
>

I haven't looked for it, so I don't know if something like that exists for 
Go.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/fcb30a5b-6fb1-4241-ad0c-2b047565d320n%40googlegroups.com.

[go-nuts] [ANN] Interactive 2D graphics on an HTML canvas via WebSockets

[Frederik Zipp]

I often find myself wanting to visualize simple graphics or even 
interactive animations from a Go program without resorting to 
platform-dependent or Cgo-based libraries, so I created this Go module:

https://github.com/fzipp/canvas

It streams drawing operations and keyboard/mouse/touch events to and from a 
browser canvas via WebSockets.

It is loosely inspired by the protocol of the 
https://p9f.org/magic/man2html/3/draw device.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/d7203970-1e34-48ab-b72b-4be78668277cn%40googlegroups.com.

Re: [go-nuts] [ generics] Moving forward with the generics design draft

[Frederik Zipp]

Ian Lance Taylor schrieb am Dienstag, 25. August 2020 um 00:35:33 UTC+2:

> I've seen objections that a language change for generics should not 
> implicitly pull in a change to non-generic code. That seems fair. It 
> may be the right thing to do, but it should be justified separately. 
> So we're going to start with "any" only being accepted as a type 
> constraint, and we can discuss making the name available for all uses 
> separately, probably on issue 33232.
>

I understand the motivation, but I hope this artificial restriction is 
eventually lifted, because I find special cases and exceptions to 
generality make a language more confusing to learn ("Why can I use this 
here but not there, even though it's referring to the same thing?"). 

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/2c13095f-ccce-43cc-9e52-f3ecd0bba733n%40googlegroups.com.

Re: [go-nuts] [generics] Type list syntax

[Frederik Zipp]

Ian Lance Taylor schrieb am Mittwoch, 19. August 2020 um 00:39:16 UTC+2:

> Yes, but here you are assigning the value struct{}{} to the type S. 
> That's not how type arguments work: type arguments are not assigned to 
> type parameters. Instead, the body of a generic function or type is 
> instantiated with the type argument. In a generic function, rather 
> than assigning a value struct{}{} to type S, we are replacing 
> instances of S in F with struct{}. But struct{} has no methods. So 
> can you call method M on an argument whose type is the type parameter? 
> Why or why not? 
>

Thanks for the explanation. 

Given this setup:

type S struct{}
func (s S) M() {}

func F1[T S](s T) { s.M() }
func F2[T struct{}](s T) {}

The instantiations would have to be:

F1[S] :: func(S)
F1[struct{}] :: func(S)

F2[struct{}] :: func(struct{})
F2[S] :: func(struct{})

Non-interface/non-"anyof" constraints would always be instantiated as 
themselves.
I can see that this might be surprising. Given that it doesn't add any 
value over normal function parameters it is probably not worth it.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/9087e39e-65f0-49bc-8952-d50d6353d256n%40googlegroups.com.

Re: [go-nuts] [generics] Type list syntax

[Frederik Zipp]

Ian Lance Taylor schrieb am Dienstag, 18. August 2020 um 21:26:23 UTC+2:

> What would it mean to permit any type as a constraint? 
>

Each type would match exactly the same types it would match in a plain old 
function parameter list:

type MyStruct struct{}
func (s MyStruct) M() {}

== Type parameter list ==

[T int] // matches 1 type; useless, just for the sake of consistency
[T MyStruct]  // matches MyStruct and 
struct{}; useless as well
[T struct{}] // matches MyStruct and 
struct{}; useless as well
[T interface{String() string}]
[T anyof{float32, float64}] // replacement for type lists in the current 
draft

== Plain old function parameter list ==

(x int) // matches 1 type
(x MyStruct)  // matches MyStruct and 
struct{}
(x struct{}) // matches MyStruct and 
struct{}
(x interface{String() string})
(x anyof{float32, float64}) // maybe in the future

 

> I actually looked into this, to see if we could say that any type 
> could be used as a constraint, and say that a type parameter 
> constraint would permit any type argument that is assignable to the 
> constraint type. Unfortunately that leads to some odd behavior. If 
> we use a named type as the constraint, it may have methods. But we 
> can use a corresponding type literal as a type argument. That would 
> add methods to a type literal with no explicit type conversion. 
>

But isn't that already the case with normal function parameters?

package main

type S struct{}

func (s S) M() {}

func F(s S) {
s.M()
}

func main() {
// no explicit type conversion from struct{} to S
F(struct{}{})
}

https://play.golang.org/p/gDQfYUbe74w
 

> Similarly, if we use a type literal as a type, we can use a defined 
> type as a type argument. But the generic function could assign the 
> type parameter to some other defined type, and now we have a generic 
> function that could not be compiled if we simply substituted the type 
> argument for any instance of the type parameter. 
>

Same here:

package main

type S struct{}

func (s S) M() {}

func F(s struct{}) {
var x S = s
_ = x
}

func main() {
// no explicit type conversion from S to struct{}
F(S{})
}
 

> And I don't see what we gain by following that path. 
>

It would mostly be for the sake of consistency, and as a justification for 
a hypothetical sum type like `anyof` (as a replacement for type lists in 
interfaces) to be usable as a constraint.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/86a3a82d-6f63-4efe-b72b-81bd1efabfa1n%40googlegroups.com.

Re: [go-nuts] [generics] Type list syntax

[Frederik Zipp]

axel.wa...@googlemail.com schrieb am Dienstag, 18. August 2020 um 20:47:12 
UTC+2:

> We already have a way to express "any of a certain subset of types", which 
> are interfaces, so using them for constraints is natural.
>

I'd argue that every type expresses a certain subset of types, not just 
interfaces. For the other types the size of the subset just happens to be 1 
(each containing just itself). So every type should be usable as 
constraint. Types, constraints, ... I don't see a difference anymore. 
Constraints are just types used in the type parameter list on the left.
 

> it's about avoiding a new *concept*.
>

Type lists are still a new concept. Just because they hide inside 
interfaces doesn't mean that they are not a new concept. I'd prefer it to 
be honest and give them a name, with the possibility to use them as sum 
types in the future.
 

> No, it is neither the same, nor is it nonsensical. `interface{ type int }` 
> is any type with *underlying type* `int`, not just `int`. It adds some 
> expressive power. I'm not sure how important that expressive power is, but 
> it's more than zero.
>

On the go2go.dev branch they recently made a change to use the actual (not 
underlying) types of type list elements for interface satisfaction: 
https://github.com/golang/go/commit/af48c2e84b52f99d30e4787b1b8d527b5cd2ab64
 

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/96914146-3f4e-4972-a18a-3d6b957acb90n%40googlegroups.com.

Re: [go-nuts] [generics] Type list syntax

[Frederik Zipp]

The more I think about it the less I understand why type list should reside 
inside interfaces. I can only think of two reasons:

1) Avoid a new keyword for type lists.
2) The idea that only interfaces should be able to act as constraints.

Regarding 2): Why this artificial limitation? Why not allow all types as 
constraints? Even int. It's nonsensical, but it would be like "interface{ 
type int }" in the current draft, which is nonsensical, too. The rule would 
be simple: Any type can act both as normal type and as constraint. With the 
possible exception of `anyof`s, until there is a solution to use them as 
regular types as well.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/8711bcf9-6ebe-4014-9034-d0a642078791n%40googlegroups.com.

Re: [go-nuts] [generics] Type list syntax

[Frederik Zipp]

Frederik Zipp schrieb am Dienstag, 18. August 2020 um 19:44:05 UTC+2:

> I agree it is a weird combination. Ideally it would be:
>
> 1. `anyof` declarations containing only types, usable as constraints and 
> types
> 2. `interface` declarations containing only methods, usable as constraints 
> and types
> 3. n/a
>  
> But then Go would introduce both generics and sum types at the same time, 
> which does not seem to be feasible due to unsolved questions like the 
> zero-value issue.
>

Of course, it would be possible to allow usage of `anyof`s only as 
constraints, with the option to allow them as general types in the future. 
The cost is a new keyword, though.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/afb4ebed-25a4-456a-93b1-1a891b322343n%40googlegroups.com.

Re: [go-nuts] [generics] Type list syntax

[Frederik Zipp]

axel.wa...@googlemail.com schrieb am Dienstag, 18. August 2020 um 19:19:32 
UTC+2:

> 1. `anyof` declarations, only usable as types
> 2. `interface` declarations containing only methods, usable as constraints 
> and types
> 3. `interface` declarations containing methods and type-lists ("embedded 
> `anyof`s), only usable as constraint.
>

I agree it is a weird combination. Ideally it would be:

1. `anyof` declarations containing only types, usable as constraints and 
types
2. `interface` declarations containing only methods, usable as constraints 
and types
3. n/a
 
But then Go would introduce both generics and sum types at the same time, 
which does not seem to be feasible due to unsolved questions like the 
zero-value issue.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/26c88fef-3235-4107-8483-b11ff0e9aaa5n%40googlegroups.com.

Re: [go-nuts] [generics] Type list syntax

[Frederik Zipp]

axel.wa...@googlemail.com schrieb am Dienstag, 18. August 2020 um 17:44:16 
UTC+2:

> I think in the overwhelmingly common case (a type-list being a list of 
> identifiers or short type-constructors like channels or slices), having a 
> line per item takes up a lot of vertical real-estate for little use. 
>

Both options, single line and multi-line, are still available with curly 
braces and semicolons, but in the multi-line case you do not have to manage 
trailing commas, and the first line containing type(s) is not indented 
differently than the following lines.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/b2cfd94c-50d0-48df-b371-b018c08b4a23n%40googlegroups.com.

Re: [go-nuts] [generics] Type list syntax

[Frederik Zipp]

Jan Mercl schrieb am Dienstag, 18. August 2020 um 16:45:54 UTC+2:

> I don't think so. The type list in this case is syntactically just an 
> identifier list, i.e not a list containing possibly eg. type  
> literals/anonymous types. 
>

I just looked into the draft design again: If composite types like slices 
and structs are allowed, as discussed in [1] and [2], then it is not just 
an identifier list.

[1] Composite types in constraints 


type byteseq interface {
type string, []byte
}

[2] Notes on composite types in type lists 


type structField interface {
type struct { a int; x int },
struct { b int; x float64 },
struct { c int; x uint64 }
}

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/48c0d6fb-16ce-4495-b520-d4a28166c122n%40googlegroups.com.

Re: [go-nuts] [generics] Type list syntax

[Frederik Zipp]

Jan Mercl schrieb am Dienstag, 18. August 2020 um 16:45:54 UTC+2:

> i.e not a list containing possibly eg. type literals/anonymous types. 
>

Yes, I wanted to interpret a type list conceptually as an anonymous type 
embedded in an interface.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/d202511e-cf2d-44da-afc6-feea3b579911n%40googlegroups.com.

[go-nuts] [generics] Type list syntax

[Frederik Zipp]

The draft syntax for type lists is a comma separated list:

type SignedInteger interface {
type int, int8, int16, int32, int64
}

Wouldn't it be more consistent with existing Go syntax regarding types if 
it was a semicolon separated list in curly braces?

type SignedInteger interface {
type {int; int8; int16; int32; int64}
}

With automatic semicolon insertion:

type SignedInteger interface {
type {
int
int8
int16
int32
int64
}
}

At least that's how 'struct' and 'interface' separate their items.

If some day, somehow, type lists should emerge from 'interface' as 
non-nilable sum types, the natural syntax would be:

type MySum type {
A
B
}

var mySum type{A; B}

Even if this will never happen, this thought experiment suggests that curly 
braces and semicolons are the more Go-like syntax choice for type lists.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/f1c5ef30-833b-4fd7-b6a6-68cef4f7ec9fn%40googlegroups.com.

Re: [go-nuts] [Generics] Constraints package name

[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.

>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/7a189321-ff08-4ca7-a7fd-fe00fc9ce613n%40googlegroups.com.

Re: [go-nuts] Generics and parentheses

[Frederik Zipp]

jlge...@gmail.com schrieb am Montag, 17. August 2020 um 19:13:45 UTC+2:

>
>- No support covariance or contravariance. Maybe I am on shaky ground 
>in terms of my understanding but doesn't this mean, for instance, that if 
> I 
>have two interfaces, Foo and Bar, and a third composite interface, FooBar, 
>which consists of Foo and Bar, that a function with a generic parameter T 
>constrained by Foo would not accept a type that implements FooBar? If i am 
>incorrect, where does this come into play?
>
> What you describe does work: https://go2goplay.golang.org/p/5bLN7fDMVGN

2) I don't see syntax for directly applying multiple constraints to a 
> generic type. Is this achievable only via interface composition? 
>

Yes, and it can be inlined as usual:

func Example[T interface{Foo; Bar}](s []T) {
}

Although naming complex types is a good idea. 

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/d4cce9ed-f84c-415c-946d-73c9a63eebfen%40googlegroups.com.

Re: [go-nuts] [Generics] Constraints package name

[frederik . zipp]

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.

-- 
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+unsubscr...@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.

[go-nuts] [Generics] Constraints package name

[frederik . zipp]

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

-- 
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+unsubscr...@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.