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 i
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
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 exi
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
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
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 in
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
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 interfa
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 subscribe
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
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 littl
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
>
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 con
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 allo
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
i
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 param
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
> instant
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
18 matches
Mail list logo
