Re: [go-nuts] Re: raw bit types without arithmetic

g bitwise operations on byte arrays (of the same >> length)? >> >> On Monday, May 13, 2024 at 2:51:19 PM UTC-6 jimmy frasche wrote: >>> >>> I'm not 100% sure if this is a good idea but it's been knocking around >>> in my head all week so I thought I'd share i

[go-nuts] raw bit types without arithmetic

I'm not 100% sure if this is a good idea but it's been knocking around in my head all week so I thought I'd share in case it has any merit: Introduce bitsN types for N=8, 16, 32, 64, 128, 256, and 512. These are similar to uintN but they are unordered and have no arithmetic operations defined.

Re: [go-nuts] Why is type inference still so rudimentary?

I wish there were more cases where the types could be elided. Always leaving it off would be a bad idea but how much to put in should be at the author's discretion. There are times when it clarifies but more times when it just adds extra steps. I know that the current rules have justifications but

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

Aug 21, 2020 at 3:03 PM Axel Wagner wrote: > > On Fri, Aug 21, 2020 at 11:46 PM Ian Lance Taylor wrote: >> >> Yes, there are various such possibilities. >> >> What jimmy frasche said above is correct: nothing changes in the case >> of a type switch of a type

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

I'd assume that would fail to compile as you're returning a []T not a []int On Fri, Aug 21, 2020 at 2:07 PM roger peppe wrote: > > > On Fri, 21 Aug 2020 at 01:28, Ian Lance Taylor wrote: >> >> After many discussions and reading many comments, we plan to move >> forward with some changes and

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

To clarify on the type switches, would it have to be used like this: type C interface { type X, Y } func f(x X) X { return x } func g[T C](v T) T { switch v { case X: // to use v as an X // we must convert x0 := X(v) x1 := f(x0) // to use x1 as a T // we must

Re: [go-nuts] [ generics ] Added constraint type inference to the design draft

If I have func F[type E interface{}, S constraints.Slice[E]]() S are the following equivalent: F[int, []int] F[int] F[[]int] or are only 2 of the 3 permissible? Does that change if I swap the type parameters? On Thu, Aug 13, 2020 at 4:31 PM Michael Jones wrote: > > Yes, thank you. In

Re: [go-nuts] [ generics ] Added constraint type inference to the design draft

I don't care for the (type T Equaler) example. It makes one thing look like another. The rest seems interesting. Obviating and generalizing the * syntax is certainly promising and a nice justification for type lists. Would the constraints package have Pointer[E], Slice[E], and so on? What

Re: [go-nuts] A few thoughts on type parameters

Most of the code I'd write with generics would take a func or something satisfying an interface to set the operations if necessary. I'd use type lists as a handy way for the user to default those to operators. Interface literals and lambdas would be just as useful here. I probably wouldn't bother

Re: [go-nuts] Generics and parentheses

I didn't care about () except for having to then have extra parens around types in a lot of places which was very annoying and came up often. If [] fixes that, great! On Wed, Jul 15, 2020 at 2:47 PM Ian Lance Taylor wrote: > > On Wed, Jul 15, 2020 at 2:36 PM Randall O'Reilly wrote: > > > >

Re: [go-nuts] draft design for // +build replacement

Running find -name "*_*.go" | xargs grep " +build" on goroot shows a lot of files with redundant build tags or additional constraints not present in the file name so they don't seem like much of a single point of truth. I'd be fine with removing file names sometimes implying build tags. Add build

Re: [go-nuts] [generics] type list suggestion

t 3:03 PM jimmy frasche wrote: > > > > Fair enough that I'd missed the last sentence. > > > > However, if you mark the types that require exact matches you can't > > reuse the same sigil in type assertion/switches, so it's unclear how > > those would work. >

Re: [go-nuts] [generics] type list suggestion

, 2020 at 2:40 PM Ian Lance Taylor wrote: > > On Sat, Jun 20, 2020 at 3:51 PM jimmy frasche wrote: > > > > I really like how the latest generics draft has progressed, fantastic > > work. The only thing that doesn't really feel perfect yet is type > > lists. > > &g

[go-nuts] [generics] type list suggestion

I really like how the latest generics draft has progressed, fantastic work. The only thing that doesn't really feel perfect yet is type lists. I like the idea of all constraints being interfaces and I get why interfaces with type lists and/or comparable are only constraints for now. I'd rather

Re: [go-nuts] [generics] the empty type list

17:26 Jesper Louis Andersen >>> wrote: >>>> >>>> It is a type which cannot be inhabited by a term. These exist and often >>>> have uses. As Bryan wrote they also completes the type lattice, so >>>> rejecting them is often a lot of wo

Re: [go-nuts] [generics] the empty type list

ce, so >>> rejecting them is often a lot of work for little gain. >>> >>> If you want examples, look up phantom types, where an uninhabited type is >>> used as a tag for ensuring compile time restrictions. >>> >>> On Wed, Jun 17, 2020, 2

Re: [go-nuts] [generics] the empty type list

I think that second error is a bug. I would expect that case to be the same as if I wrote a type list that was just int (and hence not the empty type list). On Wed, Jun 17, 2020 at 4:33 PM jimmy frasche wrote: > > If I merge the two examples I still get an error > https://go2goplay.gol

Re: [go-nuts] [generics] the empty type list

If I merge the two examples I still get an error https://go2goplay.golang.org/p/TNYLDLokGCQ prog.go2:21:2: int does not satisfy Z (int not found in ⊥) On Wed, Jun 17, 2020 at 4:24 PM Ian Lance Taylor wrote: > > On Wed, Jun 17, 2020 at 3:52 PM jimmy frasche wrote: > > > > Th

Re: [go-nuts] [generics] the empty type list

The only case I mean is when the intersection of the type lists is ∅. That's easy to check and always wrong afaict. On Wed, Jun 17, 2020 at 3:47 PM Ian Lance Taylor wrote: > > On Wed, Jun 17, 2020 at 1:09 PM jimmy frasche wrote: > > > > This isn't a bug per se, but I can fil

[go-nuts] [generics] the empty type list

This isn't a bug per se, but I can file one if requested. https://go2goplay.golang.org/p/AWynhg6ya7h Since embedding interfaces with type lists uses the intersection of the items in the type list, it's possible to create an interface that cannot be satisfied by any type. Currently this does not

Re: [go-nuts] Contracts and fused multiply add

that you could write the must-FMA version as: func maMustFMA(type T Number)(a, b, c T) T { if Kind(a) == Float { return T(math.Fma(float64(a), float64(b), float64(c))) } return a*b + c } } On Wed, Sep 12, 2018 at 11:08 AM jimmy frasche wrote: > > On Wed, Sep 12, 2018

Re: [go-nuts] Contracts and fused multiply add

On Wed, Sep 12, 2018 at 11:02 AM Ian Lance Taylor wrote: > You could perhaps choose an implementation based on unsafe.Sizeof. > But I agree that it's pretty ugly. Only if the contract were t * t + t < .1 Part of the construction was that it accepted more than just floating points. -- You

[go-nuts] Contracts and fused multiply add

Given a platform that supports the fused multiply add (FMA) instruction and the code: contract MA(t T) { t * t + t } func ma(type T MA)(a, b, c T) T { return a*b + c } Does the compiled-for-any-type version support the FMA optimization when called with a floating-point type? If

Re: [go-nuts] Re: Generic types - functions and methods on instantions

I think it would work with interfaces if the interfaces (generic or not) can themselves specify generic methods, like interface { Foo(type T)(T) T } You need to be able to invoke methods on a generic type where the method is not specialized for the instantiation so I don't see why it should

Re: [go-nuts] Re: Scrapping contracts (was: "Generics as bultin typeclasses")

There are two parts to interfaces. The interface value—the box that things are stored in at runtime. The interface type—the specification for what things you are allowed to put in that box at compile time. Using the interface type to constrain type parameters at compile-time does not

Re: [go-nuts] Re: Generics as builtin typeclasses

On Sun, Sep 9, 2018 at 12:46 AM Ian Lance Taylor wrote: > To me contracts aren't implicit or roundabout at all, at least not > when it comes to which types they permit. They are very direct and > straightforward, and they really could not be simpler. But clearly > many people disagree. Perhaps

Re: [go-nuts] Re: Generics as builtin typeclasses

> > I get that it avoids introducing those properties directly into the > > language but it also locks the language into those properties. You can > > never change https://github.com/golang/go/issues/19113 after > > introducing contracts because there could be a contract somewhere that > > uses 1

Re: [go-nuts] Re: Generics as builtin typeclasses

"Any unsigned number" would allow generic versions of the math/bits functions, though they'd have to dispatch on unsafe.Sizeof internally, as a type switch would miss type Uint uint But that would presumably be DCE'd if specialized. Allowing more types than intended isn't always bad. If I have

Re: [go-nuts] Re: Generics as builtin typeclasses

On Fri, Sep 7, 2018 at 6:10 AM Ian Lance Taylor wrote: > > On Thu, Sep 6, 2018 at 4:29 PM, Axel Wagner > wrote: > > > > The other day I had a lengthy conversation with Rog Peppe, David Crawshaw > > and Nate Finch on twitter and I'd argue that neither of us would really > > count as a Go-novice

Re: [go-nuts] Re: Generics as builtin typeclasses

> > Hypothetically, if Go introduced generics where you couldn't write > > min/max but included min/max builtins, what's the next smallest > > example where operators are necessary? > > // Contains returns whether v is in the slice s. > func Contains(type T)(s []T, v T) bool { > for _, x :=

Re: [go-nuts] Re: Generics as builtin typeclasses

I meant without having to use a wrapper but still accepting all three. I certainly agree that it not the Go way or the way to go. On Thu, Sep 6, 2018 at 3:16 PM Axel Wagner wrote: > > On Thu, Sep 6, 2018 at 11:36 PM jimmy frasche wrote: >> >> To unify those cases you need some

Re: [go-nuts] A thought on contracts

If the contract for a type is entirely inferred in order to know the types it accepts you have to read all of its code, every line. The contract let's you boil that down to the salient points so you can read line a few lines instead of a few hundred or a few thousand. On Thu, Sep 6, 2018 at 3:15

Re: [go-nuts] Why can't we use < > for the Go generic parameters ?

I'd quite prefer [] over (). It would make F[t](v) distinct from F(x)(y) even if it's not distinct from m[x](y). On Thu, Sep 6, 2018 at 3:02 PM Ian Lance Taylor wrote: > > On Thu, Sep 6, 2018 at 2:03 PM, jimmy frasche wrote: > > > > Wouldn't there be an issue with fp := AFunc[

Re: [go-nuts] Re: Generics as builtin typeclasses

> This is clearly a key issue. I happen to think that contracts are > fairly clear for the reader: take your type argument and see if the > contract body works. I feel that everyone who knows Go will be able > to do that. But maybe that's just me. For complicated contracts—and I mean even ones

Re: [go-nuts] Why can't we use < > for the Go generic parameters ?

I meant that if the instantiation syntax is T. Though it'd probably have to treat a >> token as two separate > in declarations which is annoying. On Thu, Sep 6, 2018 at 2:07 PM Jan Mercl <0xj...@gmail.com> wrote: > > > > On Thu, Sep 6, 2018, 23:03 jimmy fra

Re: [go-nuts] Why can't we use < > for the Go generic parameters ?

Wouldn't there be an issue with fp := AFunc[int] ? Though for that matter I wouldn't mind if the type part were repeated for instantiations like AFunc[type int] or even AFunc(type int) For that matter, always writing type would let you use < > since the parser could plausibly enter a separate

Re: [go-nuts] Re: Generics as builtin typeclasses

Contracts are a brilliant solution to the problem on an intellectual level. I really am impressed by how deftly they tackle the stated problem. But I am concerned about their usability on the practical level. The idea is simple but its user interface is not. I don't buy the claim that it's okay

Re: [go-nuts] Go += Package Versioning

Is there a story for a module that changes domains, like when google code shutdown or moving to a custom domain for vanity import paths? Having directives to say "find earlier versions here" or "find later versions" here seems like it would help downgrades/upgrades. If one of those old domains

Re: [go-nuts] Library for implementing package matching similar to how "go build ./..." does it?

I have not used it personally but I believe this is what you are looking for: https://godoc.org/golang.org/x/tools/go/buildutil#ExpandPatterns On Mon, Oct 9, 2017 at 11:17 PM, wrote: > I'm looking for a library or function that implements the same logic that > many of Go's

Re: [go-nuts] Re: important

I didn't get that email either. On Mon, Oct 9, 2017 at 9:51 AM, Jan Mercl <0xj...@gmail.com> wrote: > > On Mon, Oct 9, 2017 at 6:43 PM Ian Lance Taylor wrote: > >> Didn't I answer this question already? > > Obviously you did, I can see your answer in the web interface, but if

Re: [go-nuts] Re: Proposal: Just Use GitHub

It's easy to focus on the darker turns that thread took, but it also led to a lot of good discussion. It got work restarted on https://github.com/golang/go/issues/18517 and led to the following issues being filed: - https://github.com/golang/go/issues/21980 -

Re: [go-nuts] Re: Go 1.9 is released

Thanks for all the great work—lots of exciting changes in this release! On Thu, Aug 24, 2017 at 3:52 PM, Nathan Kerr wrote: > Congrats! > > I updated my Go Release Timeline and When Should You Upgrade Go? pages. > > On Friday, August 25, 2017 at 12:44:25 AM UTC+2, Chris

Re: [go-nuts] multiply and divide

There's https://github.com/golang/go/issues/19623 for making int arbitrary precision in Go2 (yes, please) there could also be an arbitrary precision float to go with float32/float64 :D On Sat, Aug 19, 2017 at 8:04 AM, Michael Jones wrote: > I would REALLY like to see big

Re: [go-nuts] Is it harmful to always return invalid values on a non-nil-error?

I never return a broken value with an error because there are occasions where returning both a value and an error make sense, such as a partial read. More than anything else, I'd rather make it clear that this is not one of those cases so I don't confuse myself later when I'm trying to track down

Re: [go-nuts] Re: Gracefully Shutdown File Server

Maybe go run is eating the signal? Does it still misbehave with go build? On Fri, Mar 10, 2017 at 12:18 PM, Bruno Albuquerque wrote: > I am not very familiar with the shutdown process yet (I did not try to use > it anywhere), but the documentation seems to imply that what you

Re: [go-nuts] How can print MAP data without randomized?

You can create a slice of the keys in any order you want and use that to control the iteration. Map iteration is always randomized. https://play.golang.org/p/yGDUNSFMSG On Thu, Feb 9, 2017 at 1:08 PM, wrote: > hi > How can print MAP data without randomized? > > -- >

Re: [go-nuts] Unary +

Even if you disagree with Iverson check out https://en.wikipedia.org/wiki/Iverson_bracket notation. That's good stuff. It should be the standard notation. On Sat, Aug 20, 2016 at 1:24 PM, Bakul Shah wrote: > Thank goodness for loony ideas, eh? I learned a lot from Iverson’s

Re: [go-nuts] Re: os.exec.Command and non-nil return status

Sorry for bumping an oldish thread, but I just ran into this trying to propagate an exit code. I didn't find anything searching that was sufficiently platform-independent, but a little spelunking into the stdlib source bore fruit, so I thought I'd share my solution. If you have an