Re: [go-nuts] Which error handling pattern do you prefer?
FWIW (which may not be much) I've settled on explicitly naming my return
values in the function declaration. If the function returns include an
error, I name always name it err. The general pattern is
func foo() (v someType, err error) {
err = doSomething()
if err != nil {
err = fmt.Errorf("some context: %v", err)
return
}
err = doNextThing()
if err != nil {
err = fmt.Errorf("some context: %v", err)
return
}
// etc
return
}
Naming the error solves the initial := problem. As for shadowing, I make
it a point never to do a := assignment involving err. For example, if I
need to call os.Open, I do
var f *os.File
f, err = os.Open(...)
I tend to use other names for errors only when it's something I can fix
within the local scope.
At first I tried hard to avoid the verbosity. Now I use a few helpful
snippets to reduce keystrokes and an editor plugin the partially fades any
block that starts with "if err != nil". The latter works amazingly well
(for me at least) to reduce visual clutter. I like it much better than one
I tried that auto-folds error blocks. It made me waste time unfolding them
to see what was inside :-)
YMMV, of course.
On Friday, November 12, 2021 at 11:15:21 AM UTC-5 david@gmail.com wrote:
> On Fri, Nov 12, 2021 at 7:48 AM Miguel Angel Rivera Notararigo <
> ntr...@gmail.com> wrote:
>
>> I tend to use errX (X is adapted according to context) for function
>> scoped errors, and err for block scoped errors
>>
>> func MyFunc() error {
>>> v, errDS := doSomething()
>>> ...
>>> errDA := doAnotherthing()
>>> }
>>>
>>
>> if err := doAnotherthing(); err != nil {
>>> return err
>>> }
>>>
>>
>> That way you don't shadow errors.
>>
>
>
> I can't +1 this enough.
>
> I've caught *so* many bugs from shadowed errors (and re-used error
> variables). I consider it a rather bad anti-pattern to have a single err
> variable
> that's reused throughout a scope.
> If you have unique error variable names and you forget to do something
> with an error that you've assigned a name you automatically get unused
> variable compile-errors. (just this is enough to be worthwhile)
>
>
> With that said, constraining the scope using the initializer statement on
> an if (or switch) statement suffices when you don't need any other return
> values, at which point I may use the err variable-name (although I often
> make those unique for clarity anyway).
>
>> --
>> 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/CAF9DLCmR4ZdnVs4A28BSrPcbiHsQ_ufub5cSPjCt2SDy2dA1xA%40mail.gmail.com
>>
>>
>> .
>>
>
--
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/6b493efc-79ad-43f7-8730-91abd9b6c9cfn%40googlegroups.com.
Re: [go-nuts] How the scopes of type parameters are defined?
On Fri, Nov 12, 2021 at 10:49 PM Ian Lance Taylor wrote:
> On Fri, Nov 12, 2021 at 9:23 AM 'Axel Wagner' via golang-nuts
> wrote:
> >
> > On Fri, Nov 12, 2021 at 6:20 PM tapi...@gmail.com
> wrote:
> >>
> >> How much complicated? Is it similar to
> >>
> >> func foo(int int) {}
> >
> >
> > No. As I said, the situation is different, as type-parameters must be
> able to be self- and mutually referential.
>
> The scope of regular parameters starts at the beginning of the
> function body (https://golang.org/ref/spec#Declarations_and_scope,
> rule 4 in the list of rules).
>
> The scope of a type parameter starts at the beginning of the type
> parameter list (
> https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#mutually-referencing-type-parameters
> ).
>
Just to nitpick, for eventual consideration when writing the spec. This
would, AIUI, imply that one of the above examples should compile, namely:
func F[T any]() {
const T = 42
}
If there is a new, implicit block surrounding the func-declaration (similar
to how we do it for if/for/switch )
which type-parameters are bound to, the function body should be a *new*
scope and re-declaring T inside that new scope should be valid, as it's
more deeply nested.
I don't think it *should* be valid, just that the most straight forward way
to put this into rules is somewhat subtle.
>
> Ian
>
--
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/CAEkBMfGJmvRL3h5Ftdjg%2Bv955-pyx67aJO84poko6xVvdmJsfw%40mail.gmail.com.
Re: [go-nuts] What's the difference of the following two assembly instructions
On Thu, Nov 11, 2021 at 5:57 PM Shanshan He wrote: > > The two instructions are : > MOVD$"".bar.func1·f(SB), R0 > and > MOVD$"".bar.func1(SB), R0 They refer to different symbols. The middle-dot in the first instruction is just part of the symbol name. Ian -- 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/CAOyqgcUUrr-ZNQZcpeaNBCr1nRWbGJPOKvZGz87xX13FqYrGQg%40mail.gmail.com.
Re: [go-nuts] About Enums
On Fri, Nov 12, 2021 at 9:20 AM Shreyas Sreenivas wrote: > > Note, I've already looked at https://golang.org/issue/28987, > https://golang.org/issue/19814, and https://golang.org/issue/28438. All of > them require them to make a change that breaks the compatibility promise. I > want to explore another way of defining enums that is backward compatible. > > Enums as types with constrained values ... > ```go > type Operation string ( > Sum = "+" > Product = "*" > Difference = "-" > Quotient = "%" > ) > ``` The problem I see is that people want different things from enumeration types, and what they want in Go tends to depend on what is provided by other languages with which they are familiar. For example, in C there is no notion of a string associated with an enum. But on the other hand there is a common expectation that it is possible to write a loop over all enumeration values, which is easy in C but is not clearly supported by your suggested syntax. I think it's necessary to first discuss the desired set of features. Until that is done, syntax can be a distraction. Ian -- 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/CAOyqgcXZaguwh%3DG_C7BSZ0gYaZA8u3aJtMLWb6WoYac7zYOwfw%40mail.gmail.com.
Re: [go-nuts] How the scopes of type parameters are defined?
On Fri, Nov 12, 2021 at 9:23 AM 'Axel Wagner' via golang-nuts
wrote:
>
> On Fri, Nov 12, 2021 at 6:20 PM tapi...@gmail.com wrote:
>>
>> How much complicated? Is it similar to
>>
>> func foo(int int) {}
>
>
> No. As I said, the situation is different, as type-parameters must be able to
> be self- and mutually referential.
The scope of regular parameters starts at the beginning of the
function body (https://golang.org/ref/spec#Declarations_and_scope,
rule 4 in the list of rules).
The scope of a type parameter starts at the beginning of the type
parameter list
(https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#mutually-referencing-type-parameters).
Ian
--
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/CAOyqgcX95qRPFJ9B8js%3D50iYwqrynCTU0%2BW%2B2LNnJUtjVC81fw%40mail.gmail.com.
[go-nuts] Re: Unable to return multiple values only the first or the last
Your function is declared to return only a single string, and the "return" statement returns immediately from the function with that single string, so this is what you've coded it to do. If you want to return multiple values, then (1) you'll have to declare the function to return a slice of strings, and (2) you'll need to build up that slice, and return it at the end. On Friday, 12 November 2021 at 17:20:10 UTC bishwajits...@gmail.com wrote: > HI, need help in understanding what i am making mistake of not able to > return all the values. Below is the sample code from Playground. > https://play.golang.org/p/EMN830T0Lvr > -- 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/48bcd799-d6b9-4b61-8d60-84a587fd855bn%40googlegroups.com.
[go-nuts] Re: Unable to return multiple values only the first or the last
You're returning right after ranging through the first value, thus ending/exiting the function. Try: https://play.golang.org/p/0n1g8HXxobI On Friday, November 12, 2021 at 10:20:10 AM UTC-7 bishwajits...@gmail.com wrote: > HI, need help in understanding what i am making mistake of not able to > return all the values. Below is the sample code from Playground. > https://play.golang.org/p/EMN830T0Lvr > -- 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/807fb817-5294-434c-8d99-3be09cb90d50n%40googlegroups.com.
Re: [go-nuts] Re: About struct fields in type parameters
OK, I will try it several days later.
On Saturday, November 13, 2021 at 1:21:08 AM UTC+8
axel.wa...@googlemail.com wrote:
> Yes, the doc is outdated. Since then, several changes have been made to
> the design, to accomodate issues that either came up during the discussion
> or where discovered after - one of the more significant is
> https://github.com/golang/go/issues/45346, but there are others.
> That's why I said we should probably wait for the actual spec changes
> before discussing it further, as there currently is no single authoritative
> source for what will land in go 1.18.
>
> On Fri, Nov 12, 2021 at 6:18 PM tapi...@gmail.com
> wrote:
>
>> The SliceConstraint example also doesn't work.
>>
>> Is the doc I mentioned outdated?
>>
>> On Saturday, November 13, 2021 at 1:13:13 AM UTC+8 tapi...@gmail.com
>> wrote:
>>
>>> And this fails to compile, although the docs says it is valid:
>>>
>>> // sliceOrMap is a type constraint for a slice or a map.
>>> type sliceOrMap interface {
>>> []int | map[int]int
>>> }
>>>
>>> // Entry returns the i'th entry in a slice or the value of a map
>>> // at key i. This is valid as the result of the operator is always
>>> int.
>>> func Entry[T sliceOrMap](c T, i int) int {
>>> // This is either a slice index operation or a map key lookup.
>>> // Either way, the index and result types are type int.
>>> return c[i] // invalid operation: cannot index c (variable of
>>> type T constrained by sliceOrMap
>>> }
>>>
>>>
>>> On Saturday, November 13, 2021 at 1:10:30 AM UTC+8 tapi...@gmail.com
>>> wrote:
>>>
The proposal design docs (
https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md)
mentions:
// structField is a type constraint whose type set consists of some
// struct types that all have a field named x.
type structField interface {
struct { a int; x int } |
struct { b int; x float64 } |
struct { c int; x uint64 }
}
// This function is INVALID.
func IncrementX[T structField](p *T) {
v := p.x // INVALID: type of p.x is not the same for all types
in set
v++
p.x = v
}
However, it still fails to compile if all the types of the x fields are
identical.
type structField interface {
struct { a int; x int } |
struct { b int; x int } |
struct { c int; x int }
}
func IncrementX[T structField](p *T) {
v := p.x // p.x undefined (type *T has no field or method x)
v++
p.x = v // p.x undefined (type *T has no field or method x)
}
--
>> 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/785df174-2e12-49bc-a3af-f143a89cd831n%40googlegroups.com
>>
>>
>> .
>>
>
--
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/56b07f60-9928-4e21-b2f7-5358c05a9306n%40googlegroups.com.
Re: [go-nuts] Re: What is the problem of the generic use?
To be clear: You sent a follow-up E-Mail to your original code, to replace
`int` with `[]byte`. That substitution is, of course, necessary to make the
code compile. So, specifically, this compiles fine:
package main
import (
"fmt"
)
type byteview interface{string | []byte}
type ByteView[T byteview] struct {v [0]T}
func (bv ByteView[T]) Write(v T) (int, error) {
return 0, nil
}
type Writer[T byteview] interface {
Write(bs T)(int, error)
}
type ioWriter = Writer[[]byte]
func main() {
fmt.Println("Hello, playground")
}
On Fri, Nov 12, 2021 at 6:21 PM Axel Wagner
wrote:
> Why not? The comment "[]byte does not satisfy comparable" seems
> irrelevant, as you don't use that constraint anywhere. It seems pretty
> well-defined, if strange and pointless, code.
>
> On Fri, Nov 12, 2021 at 6:20 PM tapi...@gmail.com
> wrote:
>
>> fine? It should not.
>>
>> On Friday, November 12, 2021 at 3:04:20 PM UTC+8
>> axel.wa...@googlemail.com wrote:
>>
>>> Please ask an actual question, don't just post some code.
>>> FTR the code you posted (with the substitution you suggest) compiles and
>>> runs fine using gotip.
>>>
>>> On Fri, Nov 12, 2021 at 6:18 AM tapi...@gmail.com
>>> wrote:
>>>
sorry, a mistake, "int" -> "[]byte".
On Friday, November 12, 2021 at 1:08:50 PM UTC+8 tapi...@gmail.com
wrote:
>
> package main
>
> import (
> "fmt"
> )
>
> type byteview interface{string | int}
>
> type ByteView[T byteview] struct {v [0]T}
>
> func (bv ByteView[T]) Write(v T) (int, error) {
> return 0, nil
> }
>
> type Writer[T byteview] interface {
> Write(bs T)(int, error)
> }
>
> type ioWriter = Writer[[]byte] // []byte does not satisfy comparable
>
> func main() {
> fmt.Println("Hello, playground")
> }
>
--
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/5342cd82-a51f-4d9d-af79-d7a5e2a1b663n%40googlegroups.com
.
>>> --
>> 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/087f84b6-7866-4e36-8bc9-a85170a26e7en%40googlegroups.com
>>
>> .
>>
>
--
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/CAEkBMfE0H%3DQVjBoypH%2B3iSoFEzt7zFhx2a24%2B4wHp5UUu5naSw%40mail.gmail.com.
Re: [go-nuts] How the scopes of type parameters are defined?
On Fri, Nov 12, 2021 at 6:20 PM tapi...@gmail.com
wrote:
> How much complicated? Is it similar to
>
> func foo(int int) {}
>
No. As I said, the situation is different, as type-parameters must be able
to be self- and mutually referential.
>
>
>>
>>
>>>
>>>
or basically any use-case for constraint-type inference.
Even if we *could* allow it consistently, the rules for doing that
would likely be pretty complex. Better to take the relatively minor hit of
disallowing this overloading (you can always use different names for the
type-parameters, if they conflict with the constraint you want to use) than
to take the hit of complex scoping rules with lots of exceptions.
On Fri, Nov 12, 2021 at 9:48 AM tapi...@gmail.com
wrote:
> I expect the following code compilers okay, but it doesn't.
> It looks All the three "I" in the Bar function declaration are
> viewed as the type parameter, whereas the second one is
> expected as the constraint I (at least by me).
>
> package main
>
> type I interface { M() }
>
> func Foo(i I) {
> i.M()
> }
>
> func Bar[I I](i I) { // cannot use a type parameter as constraint
> i.M()
> }
>
> func main() {}
>
> --
> 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/9fc66e8e-3f99-4c3a-87f7-ce7c1a705cdcn%40googlegroups.com
>
> .
>
--
>>> 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/a4ffdc09-02cf-47af-96fc-3ebde3fc5d10n%40googlegroups.com
>>>
>>> .
>>>
>> --
> 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/3d4fc243-f3dc-4071-b6ac-8c5462061e3en%40googlegroups.com
>
> .
>
--
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/CAEkBMfEe_DQsaxjuk3ES2Px9q8H6zAxAHnUVejuyefnbxWMHFw%40mail.gmail.com.
Re: [go-nuts] Re: What is the problem of the generic use?
Why not? The comment "[]byte does not satisfy comparable" seems irrelevant,
as you don't use that constraint anywhere. It seems pretty well-defined, if
strange and pointless, code.
On Fri, Nov 12, 2021 at 6:20 PM tapi...@gmail.com
wrote:
> fine? It should not.
>
> On Friday, November 12, 2021 at 3:04:20 PM UTC+8 axel.wa...@googlemail.com
> wrote:
>
>> Please ask an actual question, don't just post some code.
>> FTR the code you posted (with the substitution you suggest) compiles and
>> runs fine using gotip.
>>
>> On Fri, Nov 12, 2021 at 6:18 AM tapi...@gmail.com
>> wrote:
>>
>>> sorry, a mistake, "int" -> "[]byte".
>>>
>>> On Friday, November 12, 2021 at 1:08:50 PM UTC+8 tapi...@gmail.com
>>> wrote:
>>>
package main
import (
"fmt"
)
type byteview interface{string | int}
type ByteView[T byteview] struct {v [0]T}
func (bv ByteView[T]) Write(v T) (int, error) {
return 0, nil
}
type Writer[T byteview] interface {
Write(bs T)(int, error)
}
type ioWriter = Writer[[]byte] // []byte does not satisfy comparable
func main() {
fmt.Println("Hello, playground")
}
>>> --
>>> 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/5342cd82-a51f-4d9d-af79-d7a5e2a1b663n%40googlegroups.com
>>>
>>> .
>>>
>> --
> 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/087f84b6-7866-4e36-8bc9-a85170a26e7en%40googlegroups.com
>
> .
>
--
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/CAEkBMfFmhVzRGL7unJZXwB2M66qOyEcP11sminfMi0iV5ZyFPw%40mail.gmail.com.
Re: [go-nuts] Re: About struct fields in type parameters
Yes, the doc is outdated. Since then, several changes have been made to the
design, to accomodate issues that either came up during the discussion or
where discovered after - one of the more significant is
https://github.com/golang/go/issues/45346, but there are others.
That's why I said we should probably wait for the actual spec changes
before discussing it further, as there currently is no single authoritative
source for what will land in go 1.18.
On Fri, Nov 12, 2021 at 6:18 PM tapi...@gmail.com
wrote:
> The SliceConstraint example also doesn't work.
>
> Is the doc I mentioned outdated?
>
> On Saturday, November 13, 2021 at 1:13:13 AM UTC+8 tapi...@gmail.com
> wrote:
>
>> And this fails to compile, although the docs says it is valid:
>>
>> // sliceOrMap is a type constraint for a slice or a map.
>> type sliceOrMap interface {
>> []int | map[int]int
>> }
>>
>> // Entry returns the i'th entry in a slice or the value of a map
>> // at key i. This is valid as the result of the operator is always
>> int.
>> func Entry[T sliceOrMap](c T, i int) int {
>> // This is either a slice index operation or a map key lookup.
>> // Either way, the index and result types are type int.
>> return c[i] // invalid operation: cannot index c (variable of
>> type T constrained by sliceOrMap
>> }
>>
>>
>> On Saturday, November 13, 2021 at 1:10:30 AM UTC+8 tapi...@gmail.com
>> wrote:
>>
>>> The proposal design docs (
>>> https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md)
>>> mentions:
>>>
>>> // structField is a type constraint whose type set consists of some
>>> // struct types that all have a field named x.
>>> type structField interface {
>>> struct { a int; x int } |
>>> struct { b int; x float64 } |
>>> struct { c int; x uint64 }
>>> }
>>>
>>> // This function is INVALID.
>>> func IncrementX[T structField](p *T) {
>>> v := p.x // INVALID: type of p.x is not the same for all types
>>> in set
>>> v++
>>> p.x = v
>>> }
>>>
>>> However, it still fails to compile if all the types of the x fields are
>>> identical.
>>>
>>> type structField interface {
>>> struct { a int; x int } |
>>> struct { b int; x int } |
>>> struct { c int; x int }
>>> }
>>>
>>> func IncrementX[T structField](p *T) {
>>> v := p.x // p.x undefined (type *T has no field or method x)
>>> v++
>>> p.x = v // p.x undefined (type *T has no field or method x)
>>> }
>>>
>>>
>>>
>>> --
> 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/785df174-2e12-49bc-a3af-f143a89cd831n%40googlegroups.com
>
> .
>
--
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/CAEkBMfENi7igdxz0ZnmE0rda-6gnH6MEo80LhYF8RLWYRbErYw%40mail.gmail.com.
[go-nuts] About Enums
Note, I've already looked at https://golang.org/issue/28987,
https://golang.org/issue/19814, and https://golang.org/issue/28438. All of
them require them to make a change that breaks the compatibility promise. I
want to explore another way of defining enums that is backward compatible.
*Enums as types with constrained values*
Say we have an enum for mathematical operations, we can define it currently
with iota like so:
```go
type Operation int
const (
Uknown Operation = iota // zero value
Sum
Difference
Product
Difference
)
```
There are a few problems here:
1. `Operation(100)` is valid even though it shouldn't be. Sure, we can use
static analysis tools but it'd be a lot better if the compiler checked this
for us.
2. Although I've never seen anyone do it, you can redefine the same values
in a different place with different names.
3. Zero values can become complicated easily.
4. Very often we want enums with string representations. We can define a
`.String()` method that uses a map, but it could be considered boilerplate.
For example, we would need to define the below method for the `Operation`
type
```go
func (o Operation) String() string {
symbols := map[Operation]string{
Sum: "+" ,
Product: "*",
Difference: "-",
Quotient: "/",
}
return symbols[o] // assuming we know `o` is always a valid value
}
```
I think a much better solution would be the below syntax
```go
type Operation string (
Sum = "+"
Product = "*"
Difference = "-"
Quotient = "%"
)
```
We can think of Operation as a type with an underlying type of string with
"constrained values", i.e. any variable with a type of `Operation` can only
have one of these predefined values. We can define constrained values
similarly for any type that is comparable, but not pointers.
*Usage*
```go
// using one of the values
var operator = Operator.Sum
// converting a string constant to the enum
var operator2 = Operator("+") // if the value we're trying to convert is
not a variable or doesn't have a component that's a variable, the validity
could be checked by the compiler
// conversion of a dynamic value
var str = "foo"
var operator3 = Operator(str) // panics if invalid value?
```
We get compiler time type checking, only certain values are allowed at both
compile-time and runtime (which is the point of an enum).
Downsides:
1. This could be considered syntactic sugar for `iota`, and `.String()`
2. The syntax looks out of place? This could be discussed further
3. This could potentially add complexity but IMO it's very little
Pros:
1. Better type safety
2. Fixes the problems with the current approach to enums mentioned above
3. Doesn't violate the compatibility guidelines
4. No complex enums like the ones you'd find in other languages like Rust
or Swift (specially swift)
*Some more examples*
```go
// the default underlying values would be A=0, B=1, and so on...
type Foo int (
A
B
C
D = 10 // custom value
)
// the underlying default values are "A", "B", and so on...
type Bar string (
A
B
C
D = "custom_value"
)
type FooS struct {
Foo string
Bar string
}
// no default values in this case, have to provide a value
type Foo2 FooS (
A = FooS{"a", "b"}
B = FooS{"c", "d"}
)
```
*Zero Values*
There are a few ways we handle zero values.
1. We enforce declaring a zero value
```go
type Foo struct {
foo string
}
type Bar Foo (
A = Foo{} // enforce this
B = Foo{"another"}
)
type Bar2 int {
A // zero value like the first value of iota
B
}
type Bar3 string {
A = "" // enforce this
B
}
```
2. Create an `.Zero` by default
An option, but it doesn't feel right.
3. No special naming or requirement for zero values
```go
// we can just have
type Foo string (
A
B
)
var foo = Foo("") // this represents a zero value and is allowed even
though we don't have a value that contains a zero value
```
We shouldn't allow `nil` considering the underlying types cannot be `nil`.
--
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/fec12ef6-0c05-4164-9d97-ab1d4acc9a6an%40googlegroups.com.
Re: [go-nuts] How the scopes of type parameters are defined?
On Friday, November 12, 2021 at 6:07:11 PM UTC+8 axel.wa...@googlemail.com
wrote:
> And FWIW, just to illustrate the expected complexity: We also want these
> two declarations to mean the same:
> func A[T A]()
> func B[T interface{ A }]()
> So the rules also need to accommodate that. It gets only more complicated
> from there.
>
Are the followings also intended?
func Foo[T any](T T) T { // (the 2nd) T redeclared in this block
return T // T (type) is not an expression
}
func Bar[T any](x T) T {
var T = x // T redeclared in this block
return T
}
>
> On Fri, Nov 12, 2021 at 11:03 AM Axel Wagner
> wrote:
>
>>
>>
>> On Fri, Nov 12, 2021 at 10:54 AM tapi...@gmail.com
>> wrote:
>>
>>>
>>>
>>> On Friday, November 12, 2021 at 5:33:19 PM UTC+8
>>> axel.wa...@googlemail.com wrote:
>>>
I suspect this issue is hard/impossible to avoid, because it must be
possible to self- and mutually reference type-parameters, in a way that
it's not for normal parameters, to allow to write something like
type Equaler[T any] interface {
Equal(T) bool
}
func Eq[T Equaler[T]](a, b T) bool {
return a.Equal(b)
}
>>>
>>> I don't see the same problem here. "T" and "Equaler" are two different
>>> identifiers.
>>>
>>
>> But T and T are not.
>>
>> The point I was making is that type-parameters must inherently be scoped
>> in a way that makes them visible in the type-list itself, to make writing
>> code like this possible. This isn't necessary for regular parameters and
>> it's what makes type-parameter lists special.
>>
>> I *also* said that it's probably possible to devise rules which would
>> make this possible, while allowing the example you wrote, just that those
>> rules would have to be complicated.
>>
>>
>>>
>>>
or basically any use-case for constraint-type inference.
Even if we *could* allow it consistently, the rules for doing that
would likely be pretty complex. Better to take the relatively minor hit of
disallowing this overloading (you can always use different names for the
type-parameters, if they conflict with the constraint you want to use)
than
to take the hit of complex scoping rules with lots of exceptions.
On Fri, Nov 12, 2021 at 9:48 AM tapi...@gmail.com
wrote:
> I expect the following code compilers okay, but it doesn't.
> It looks All the three "I" in the Bar function declaration are
> viewed as the type parameter, whereas the second one is
> expected as the constraint I (at least by me).
>
> package main
>
> type I interface { M() }
>
> func Foo(i I) {
> i.M()
> }
>
> func Bar[I I](i I) { // cannot use a type parameter as constraint
> i.M()
> }
>
> func main() {}
>
> --
> 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/9fc66e8e-3f99-4c3a-87f7-ce7c1a705cdcn%40googlegroups.com
>
>
> .
>
--
>>> 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/a4ffdc09-02cf-47af-96fc-3ebde3fc5d10n%40googlegroups.com
>>>
>>>
>>> .
>>>
>>
--
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/02e92a27-93a3-41ab-9955-52898d494540n%40googlegroups.com.
Re: [go-nuts] How the scopes of type parameters are defined?
Are the followings also intended?
func Foo[T any](T T) T { // (the 2nd) T redeclared in this block
return T // T (type) is not an expression
}
func Bar[T any](x T) T {
var T = x // T redeclared in this block
return T
}
On Friday, November 12, 2021 at 6:07:11 PM UTC+8 axel.wa...@googlemail.com
wrote:
> And FWIW, just to illustrate the expected complexity: We also want these
> two declarations to mean the same:
> func A[T A]()
> func B[T interface{ A }]()
> So the rules also need to accommodate that. It gets only more complicated
> from there.
>
> On Fri, Nov 12, 2021 at 11:03 AM Axel Wagner
> wrote:
>
>>
>>
>> On Fri, Nov 12, 2021 at 10:54 AM tapi...@gmail.com
>> wrote:
>>
>>>
>>>
>>> On Friday, November 12, 2021 at 5:33:19 PM UTC+8
>>> axel.wa...@googlemail.com wrote:
>>>
I suspect this issue is hard/impossible to avoid, because it must be
possible to self- and mutually reference type-parameters, in a way that
it's not for normal parameters, to allow to write something like
type Equaler[T any] interface {
Equal(T) bool
}
func Eq[T Equaler[T]](a, b T) bool {
return a.Equal(b)
}
>>>
>>> I don't see the same problem here. "T" and "Equaler" are two different
>>> identifiers.
>>>
>>
>> But T and T are not.
>>
>> The point I was making is that type-parameters must inherently be scoped
>> in a way that makes them visible in the type-list itself, to make writing
>> code like this possible. This isn't necessary for regular parameters and
>> it's what makes type-parameter lists special.
>>
>> I *also* said that it's probably possible to devise rules which would
>> make this possible, while allowing the example you wrote, just that those
>> rules would have to be complicated.
>>
>>
>>>
>>>
or basically any use-case for constraint-type inference.
Even if we *could* allow it consistently, the rules for doing that
would likely be pretty complex. Better to take the relatively minor hit of
disallowing this overloading (you can always use different names for the
type-parameters, if they conflict with the constraint you want to use)
than
to take the hit of complex scoping rules with lots of exceptions.
On Fri, Nov 12, 2021 at 9:48 AM tapi...@gmail.com
wrote:
> I expect the following code compilers okay, but it doesn't.
> It looks All the three "I" in the Bar function declaration are
> viewed as the type parameter, whereas the second one is
> expected as the constraint I (at least by me).
>
> package main
>
> type I interface { M() }
>
> func Foo(i I) {
> i.M()
> }
>
> func Bar[I I](i I) { // cannot use a type parameter as constraint
> i.M()
> }
>
> func main() {}
>
> --
> 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/9fc66e8e-3f99-4c3a-87f7-ce7c1a705cdcn%40googlegroups.com
>
>
> .
>
--
>>> 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/a4ffdc09-02cf-47af-96fc-3ebde3fc5d10n%40googlegroups.com
>>>
>>>
>>> .
>>>
>>
--
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/ec05df1e-4979-42ad-b5dc-5d3915355c57n%40googlegroups.com.
[go-nuts] Unable to return multiple values only the first or the last
HI, need help in understanding what i am making mistake of not able to return all the values. Below is the sample code from Playground. https://play.golang.org/p/EMN830T0Lvr -- 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/e802c15f-0a9f-49c4-ba55-24319958b99cn%40googlegroups.com.
Re: [go-nuts] How the scopes of type parameters are defined?
On Friday, November 12, 2021 at 6:04:01 PM UTC+8 axel.wa...@googlemail.com
wrote:
> On Fri, Nov 12, 2021 at 10:54 AM tapi...@gmail.com
> wrote:
>
>>
>>
>> On Friday, November 12, 2021 at 5:33:19 PM UTC+8
>> axel.wa...@googlemail.com wrote:
>>
>>> I suspect this issue is hard/impossible to avoid, because it must be
>>> possible to self- and mutually reference type-parameters, in a way that
>>> it's not for normal parameters, to allow to write something like
>>>
>>> type Equaler[T any] interface {
>>> Equal(T) bool
>>> }
>>> func Eq[T Equaler[T]](a, b T) bool {
>>> return a.Equal(b)
>>> }
>>>
>>
>> I don't see the same problem here. "T" and "Equaler" are two different
>> identifiers.
>>
>
> But T and T are not.
>
> The point I was making is that type-parameters must inherently be scoped
> in a way that makes them visible in the type-list itself, to make writing
> code like this possible. This isn't necessary for regular parameters and
> it's what makes type-parameter lists special.
>
> I *also* said that it's probably possible to devise rules which would make
> this possible, while allowing the example you wrote, just that those rules
> would have to be complicated.
>
How much complicated? Is it similar to
func foo(int int) {}
>
>
>>
>>
>>>
>>> or basically any use-case for constraint-type inference.
>>>
>>> Even if we *could* allow it consistently, the rules for doing that would
>>> likely be pretty complex. Better to take the relatively minor hit of
>>> disallowing this overloading (you can always use different names for the
>>> type-parameters, if they conflict with the constraint you want to use) than
>>> to take the hit of complex scoping rules with lots of exceptions.
>>>
>>> On Fri, Nov 12, 2021 at 9:48 AM tapi...@gmail.com
>>> wrote:
>>>
I expect the following code compilers okay, but it doesn't.
It looks All the three "I" in the Bar function declaration are
viewed as the type parameter, whereas the second one is
expected as the constraint I (at least by me).
package main
type I interface { M() }
func Foo(i I) {
i.M()
}
func Bar[I I](i I) { // cannot use a type parameter as constraint
i.M()
}
func main() {}
--
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/9fc66e8e-3f99-4c3a-87f7-ce7c1a705cdcn%40googlegroups.com
.
>>> --
>> 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/a4ffdc09-02cf-47af-96fc-3ebde3fc5d10n%40googlegroups.com
>>
>>
>> .
>>
>
--
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/3d4fc243-f3dc-4071-b6ac-8c5462061e3en%40googlegroups.com.
Re: [go-nuts] Re: What is the problem of the generic use?
fine? It should not.
On Friday, November 12, 2021 at 3:04:20 PM UTC+8 axel.wa...@googlemail.com
wrote:
> Please ask an actual question, don't just post some code.
> FTR the code you posted (with the substitution you suggest) compiles and
> runs fine using gotip.
>
> On Fri, Nov 12, 2021 at 6:18 AM tapi...@gmail.com
> wrote:
>
>> sorry, a mistake, "int" -> "[]byte".
>>
>> On Friday, November 12, 2021 at 1:08:50 PM UTC+8 tapi...@gmail.com wrote:
>>
>>>
>>> package main
>>>
>>> import (
>>> "fmt"
>>> )
>>>
>>> type byteview interface{string | int}
>>>
>>> type ByteView[T byteview] struct {v [0]T}
>>>
>>> func (bv ByteView[T]) Write(v T) (int, error) {
>>> return 0, nil
>>> }
>>>
>>> type Writer[T byteview] interface {
>>> Write(bs T)(int, error)
>>> }
>>>
>>> type ioWriter = Writer[[]byte] // []byte does not satisfy comparable
>>>
>>> func main() {
>>> fmt.Println("Hello, playground")
>>> }
>>>
>> --
>> 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/5342cd82-a51f-4d9d-af79-d7a5e2a1b663n%40googlegroups.com
>>
>>
>> .
>>
>
--
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/087f84b6-7866-4e36-8bc9-a85170a26e7en%40googlegroups.com.
Re: [go-nuts] Which error handling pattern do you prefer?
Nice, make it simple.
On Friday, November 12, 2021 at 3:08:31 PM UTC+8 axel.wa...@googlemail.com
wrote:
> I don't prefer either. I decide on a case-by-case basis. I generally
> ignore the question of scope, though. The relevant question (to me) is
> readability. If the statement is short, I use the one-line version,
> otherwise (or if I need to use either result after the conditional) I use
> the version with a separate statement. But that's a rule-of-thumb, as I
> said, I decide case by case.
>
> On Fri, Nov 12, 2021 at 5:05 AM Kn wrote:
>
>> Hi, guys, I want to know which error handling pattern do you prefer.
>> Following is a code snippet from go stdlib.
>>
>>
>> https://sourcegraph.com/github.com/golang/go/-/blob/src/net/http/h2_bundle.go?L1848
>>
>> Let me simplify my questions:
>>
>> Pattern1: like the code in go stdlib, in the same function, we first
>> declare one error variable, then in the following if-statement we use
>> one-liner pattern to declare a new error variable.
>>
>> ```go
>> func MyFunc() error {
>> v, err := doSomething()
>> if err != nil {
>> return err
>> }
>> // stuff about processing `v`
>>
>> if err := doAnotherthing(); err != nil {
>> return err
>> }
>>
>> // stuff about processing ...
>> }
>> ```
>>
>> I think pretty code should not only be readable but also to conform to
>> same code style. So I think why not use the already declared variable
>> before. Then we have the following pattern.
>>
>> Pattern2: Firstly doSomething() returns multiple return values and we
>> need processing `v` later, so we use `v, err := doSomething()` as before.
>> But, I think the `error` encountered is special compared to other local
>> variables, it represents a state of current function (success or failure).
>> So I think only one error variable is enough, it can be used for indicating
>> any error, no matter the error is generated from `doSomething()` or
>> `doAnotherthing()`.
>>
>> And, I didn't use the one-liner pattern which may be used for minimize
>> the variable's scope. Some people think we should use one-line pattern here
>> to conform to this rule.
>>
>> ```go
>> func MyFunc() error {
>> v, err := doSomething()
>> if err != nil {
>> return err
>> }
>> // stuff about processing `v`
>>
>> err := doAnotherthing()
>> if err != nil {
>> return err
>> }
>>
>> // stuff about processing ...
>> }
>> ```
>>
>> Of course I know the rule to minimize the variable's scope, but I think
>> error is special and consistent coding style is important and beautiful. I
>> searched the go source code, these two patterns are both used.
>>
>> I want to know which pattern do you prefer and suggested.
>>
>> Thanks!
>>
>>
>> --
>> 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/2999eca8-1cc4-475c-8f85-0d2c8b966268n%40googlegroups.com
>>
>>
>> .
>>
>
--
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/34a54f5a-78e5-4f0f-bb64-72fd16d55e03n%40googlegroups.com.
[go-nuts] Re: About struct fields in type parameters
The SliceConstraint example also doesn't work.
Is the doc I mentioned outdated?
On Saturday, November 13, 2021 at 1:13:13 AM UTC+8 tapi...@gmail.com wrote:
> And this fails to compile, although the docs says it is valid:
>
> // sliceOrMap is a type constraint for a slice or a map.
> type sliceOrMap interface {
> []int | map[int]int
> }
>
> // Entry returns the i'th entry in a slice or the value of a map
> // at key i. This is valid as the result of the operator is always int.
> func Entry[T sliceOrMap](c T, i int) int {
> // This is either a slice index operation or a map key lookup.
> // Either way, the index and result types are type int.
> return c[i] // invalid operation: cannot index c (variable of type
> T constrained by sliceOrMap
> }
>
>
> On Saturday, November 13, 2021 at 1:10:30 AM UTC+8 tapi...@gmail.com
> wrote:
>
>> The proposal design docs (
>> https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md)
>>
>> mentions:
>>
>> // structField is a type constraint whose type set consists of some
>> // struct types that all have a field named x.
>> type structField interface {
>> struct { a int; x int } |
>> struct { b int; x float64 } |
>> struct { c int; x uint64 }
>> }
>>
>> // This function is INVALID.
>> func IncrementX[T structField](p *T) {
>> v := p.x // INVALID: type of p.x is not the same for all types in
>> set
>> v++
>> p.x = v
>> }
>>
>> However, it still fails to compile if all the types of the x fields are
>> identical.
>>
>> type structField interface {
>> struct { a int; x int } |
>> struct { b int; x int } |
>> struct { c int; x int }
>> }
>>
>> func IncrementX[T structField](p *T) {
>> v := p.x // p.x undefined (type *T has no field or method x)
>> v++
>> p.x = v // p.x undefined (type *T has no field or method x)
>> }
>>
>>
>>
>>
--
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/785df174-2e12-49bc-a3af-f143a89cd831n%40googlegroups.com.
[go-nuts] Re: About struct fields in type parameters
And this fails to compile, although the docs says it is valid:
// sliceOrMap is a type constraint for a slice or a map.
type sliceOrMap interface {
[]int | map[int]int
}
// Entry returns the i'th entry in a slice or the value of a map
// at key i. This is valid as the result of the operator is always int.
func Entry[T sliceOrMap](c T, i int) int {
// This is either a slice index operation or a map key lookup.
// Either way, the index and result types are type int.
return c[i] // invalid operation: cannot index c (variable of type
T constrained by sliceOrMap
}
On Saturday, November 13, 2021 at 1:10:30 AM UTC+8 tapi...@gmail.com wrote:
> The proposal design docs (
> https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md)
>
> mentions:
>
> // structField is a type constraint whose type set consists of some
> // struct types that all have a field named x.
> type structField interface {
> struct { a int; x int } |
> struct { b int; x float64 } |
> struct { c int; x uint64 }
> }
>
> // This function is INVALID.
> func IncrementX[T structField](p *T) {
> v := p.x // INVALID: type of p.x is not the same for all types in
> set
> v++
> p.x = v
> }
>
> However, it still fails to compile if all the types of the x fields are
> identical.
>
> type structField interface {
> struct { a int; x int } |
> struct { b int; x int } |
> struct { c int; x int }
> }
>
> func IncrementX[T structField](p *T) {
> v := p.x // p.x undefined (type *T has no field or method x)
> v++
> p.x = v // p.x undefined (type *T has no field or method x)
> }
>
>
>
>
--
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/7f2e88e1-5a50-4aae-9e72-94d6b43f5f16n%40googlegroups.com.
[go-nuts] About struct fields in type parameters
The proposal design docs
(https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md)
mentions:
// structField is a type constraint whose type set consists of some
// struct types that all have a field named x.
type structField interface {
struct { a int; x int } |
struct { b int; x float64 } |
struct { c int; x uint64 }
}
// This function is INVALID.
func IncrementX[T structField](p *T) {
v := p.x // INVALID: type of p.x is not the same for all types in
set
v++
p.x = v
}
However, it still fails to compile if all the types of the x fields are
identical.
type structField interface {
struct { a int; x int } |
struct { b int; x int } |
struct { c int; x int }
}
func IncrementX[T structField](p *T) {
v := p.x // p.x undefined (type *T has no field or method x)
v++
p.x = v // p.x undefined (type *T has no field or method x)
}
--
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/451c441a-d4c1-48e5-aa1a-01118bd32f1en%40googlegroups.com.
Re: [go-nuts] Is this a known problem?
I think all of this will probably be handled with wrapper collections types and
the iterator pattern.
Generics should make this easy. It would be great is range supported this but
it seems doubtful.
> On Nov 12, 2021, at 10:37 AM, 'Axel Wagner' via golang-nuts
> wrote:
>
>
> It is still a different operation. For example, a range over a map is not
> necessarily deterministic.
>
> If you continue to ask detail-questions like this, it would be useful if you
> could provide an actual program you'd want to write using them. Otherwise, it
> makes a lot more sense to just wait for the spec-changes to be known. At that
> point, it'll be easier to talk about if a specific example does or does not
> conform to the spec.
>
>> On Fri, Nov 12, 2021 at 5:08 PM T L wrote:
>>
>>
>>> On Fri, Nov 12, 2021 at 11:54 PM Axel Wagner
>>> wrote:
>>> Oh, sorry, I just re-read. Your example still requires `range` to return
>>> distinct types, so that probably shouldn't work.
>>
>> Not this reason:
>>
>> func Bar[T []byte|map[int]byte](s T) {
>> for i, v := range s { _, _ = i, v} // cannot range over s (variable of
>> type T constrained by []byte|map[int]byte) (type set has no single
>> underlying type)
>> }
>>
>>>
On Fri, Nov 12, 2021 at 4:52 PM Axel Wagner
wrote:
The error message gives you a reason - there is no single underlying type.
This works:
type B []byte
func Bar[T []byte|B](s T) {
for range s {}
}
But yes, your example arguably should be made to work eventually. I would
suggest filing an issue about that.
> On Fri, Nov 12, 2021 at 4:47 PM tapi...@gmail.com
> wrote:
> This one doesn't compile either.
> So the range operation doesn't support values of parameter types?
>
> type MyByte byte
>
> func Bar[T []byte|[]MyByte](s T) {
> for range s {} // cannot range over s (variable of type T constrained
> by []byte|[]MyByte) (type set has no single underlying
> }
>
>> On Friday, November 12, 2021 at 11:40:53 PM UTC+8
>> axel.wa...@googlemail.com wrote:
>>> On Fri, Nov 12, 2021 at 4:29 PM tapi...@gmail.com
>>> wrote:
On Friday, November 12, 2021 at 11:10:17 PM UTC+8
axel.wa...@googlemail.com wrote:
`range s` works differently for string and []byte. In the former case
it iterates over utf8-encoded unicode codepoints, in the latter it
iterates over bytes.
>>>
>>> It is true, but why it matters here?
>>
>> Because it makes `range` different operations for the purposes of
>> determining the allowed operations on a type-parameter.
>>
>>
>>>
> On Fri, Nov 12, 2021 at 3:18 PM tapi...@gmail.com
> wrote:
>
> func Bar[T []byte|string](s T) bool {
> for _, v := range s { // cannot range over s (variable of type T
> constrained by []byte|string) (T has no structural type)
> if v > 100 {
> return true
> }
> }
> return false
> }
>
> The message is quite confusing.
> --
> 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/44b5f535-adc8-4049-ba41-638f90becc3cn%40googlegroups.com.
>>>
>>> --
>>> 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/abd83194-8198-40e8-ad12-82953f85fba5n%40googlegroups.com.
>
> --
> 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/42054eee-a9df-40d1-b148-4e5ead89ee0cn%40googlegroups.com.
>
> --
> 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/CAEkBMfHFJavSL%3DtrB8ZJgXRmyzqm3PE1ae139RLy1KkkCKkRDQ%40mail.gmail.com.
--
You received this message because you are subscribed to the Google
Re: [go-nuts] Is this a known problem?
It is still a different operation. For example, a range over a map is not
necessarily deterministic.
If you continue to ask detail-questions like this, it would be useful if
you could provide an actual program you'd want to write using them.
Otherwise, it makes a lot more sense to just wait for the spec-changes to
be known. At that point, it'll be easier to talk about if a specific
example does or does not conform to the spec.
On Fri, Nov 12, 2021 at 5:08 PM T L wrote:
>
>
> On Fri, Nov 12, 2021 at 11:54 PM Axel Wagner <
> axel.wagner...@googlemail.com> wrote:
>
>> Oh, sorry, I just re-read. Your example still requires `range` to return
>> distinct types, so that probably shouldn't work.
>>
>
> Not this reason:
>
> func Bar[T []byte|map[int]byte](s T) {
> for i, v := range s { _, _ = i, v} // cannot range over s (variable of
> type T constrained by []byte|map[int]byte) (type set has no single
> underlying type)
> }
>
>
>>
>> On Fri, Nov 12, 2021 at 4:52 PM Axel Wagner <
>> axel.wagner...@googlemail.com> wrote:
>>
>>> The error message gives you a reason - there is no single underlying
>>> type. This works:
>>>
>>> type B []byte
>>> func Bar[T []byte|B](s T) {
>>> for range s {}
>>> }
>>>
>>> But yes, your example arguably should be made to work eventually. I
>>> would suggest filing an issue about that.
>>>
>>> On Fri, Nov 12, 2021 at 4:47 PM tapi...@gmail.com
>>> wrote:
>>>
This one doesn't compile either.
So the range operation doesn't support values of parameter types?
type MyByte byte
func Bar[T []byte|[]MyByte](s T) {
for range s {} // cannot range over s (variable of type T
constrained by []byte|[]MyByte) (type set has no single underlying
}
On Friday, November 12, 2021 at 11:40:53 PM UTC+8
axel.wa...@googlemail.com wrote:
> On Fri, Nov 12, 2021 at 4:29 PM tapi...@gmail.com
> wrote:
>
>> On Friday, November 12, 2021 at 11:10:17 PM UTC+8
>> axel.wa...@googlemail.com wrote:
>>
>>> `range s` works differently for string and []byte. In the former
>>> case it iterates over utf8-encoded unicode codepoints, in the latter it
>>> iterates over bytes.
>>>
>>
>> It is true, but why it matters here?
>>
>
> Because it makes `range` different operations for the purposes of
> determining the allowed operations on a type-parameter.
>
>
>>
>>
>>>
>>> On Fri, Nov 12, 2021 at 3:18 PM tapi...@gmail.com
>>> wrote:
>>>
func Bar[T []byte|string](s T) bool {
for _, v := range s { // cannot range over s (variable of type
T constrained by []byte|string) (T has no structural type)
if v > 100 {
return true
}
}
return false
}
The message is quite confusing.
--
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/44b5f535-adc8-4049-ba41-638f90becc3cn%40googlegroups.com
.
>>> --
>> 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/abd83194-8198-40e8-ad12-82953f85fba5n%40googlegroups.com
>>
>> .
>>
> --
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/42054eee-a9df-40d1-b148-4e5ead89ee0cn%40googlegroups.com
.
>>>
--
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
Re: [go-nuts] Which error handling pattern do you prefer?
On Fri, Nov 12, 2021 at 7:48 AM Miguel Angel Rivera Notararigo <
ntr...@gmail.com> wrote:
> I tend to use errX (X is adapted according to context) for function scoped
> errors, and err for block scoped errors
>
> func MyFunc() error {
>> v, errDS := doSomething()
>> ...
>> errDA := doAnotherthing()
>> }
>>
>
> if err := doAnotherthing(); err != nil {
>> return err
>> }
>>
>
> That way you don't shadow errors.
>
I can't +1 this enough.
I've caught *so* many bugs from shadowed errors (and re-used error
variables). I consider it a rather bad anti-pattern to have a single
err variable
that's reused throughout a scope.
If you have unique error variable names and you forget to do something with
an error that you've assigned a name you automatically get unused variable
compile-errors. (just this is enough to be worthwhile)
With that said, constraining the scope using the initializer statement on
an if (or switch) statement suffices when you don't need any other return
values, at which point I may use the err variable-name (although I often
make those unique for clarity anyway).
> --
> 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/CAF9DLCmR4ZdnVs4A28BSrPcbiHsQ_ufub5cSPjCt2SDy2dA1xA%40mail.gmail.com
>
> .
>
--
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/CANrC0Bjc%2BTgHZvdY9oAqBgBUFDdd-KbkMi38bHmeYHPaDZANPA%40mail.gmail.com.
Re: [go-nuts] Is this a known problem?
On Fri, Nov 12, 2021 at 11:54 PM Axel Wagner
wrote:
> Oh, sorry, I just re-read. Your example still requires `range` to return
> distinct types, so that probably shouldn't work.
>
Not this reason:
func Bar[T []byte|map[int]byte](s T) {
for i, v := range s { _, _ = i, v} // cannot range over s (variable of
type T constrained by []byte|map[int]byte) (type set has no single
underlying type)
}
>
> On Fri, Nov 12, 2021 at 4:52 PM Axel Wagner
> wrote:
>
>> The error message gives you a reason - there is no single underlying
>> type. This works:
>>
>> type B []byte
>> func Bar[T []byte|B](s T) {
>> for range s {}
>> }
>>
>> But yes, your example arguably should be made to work eventually. I would
>> suggest filing an issue about that.
>>
>> On Fri, Nov 12, 2021 at 4:47 PM tapi...@gmail.com
>> wrote:
>>
>>> This one doesn't compile either.
>>> So the range operation doesn't support values of parameter types?
>>>
>>> type MyByte byte
>>>
>>> func Bar[T []byte|[]MyByte](s T) {
>>> for range s {} // cannot range over s (variable of type T
>>> constrained by []byte|[]MyByte) (type set has no single underlying
>>> }
>>>
>>> On Friday, November 12, 2021 at 11:40:53 PM UTC+8
>>> axel.wa...@googlemail.com wrote:
>>>
On Fri, Nov 12, 2021 at 4:29 PM tapi...@gmail.com
wrote:
> On Friday, November 12, 2021 at 11:10:17 PM UTC+8
> axel.wa...@googlemail.com wrote:
>
>> `range s` works differently for string and []byte. In the former case
>> it iterates over utf8-encoded unicode codepoints, in the latter it
>> iterates
>> over bytes.
>>
>
> It is true, but why it matters here?
>
Because it makes `range` different operations for the purposes of
determining the allowed operations on a type-parameter.
>
>
>>
>> On Fri, Nov 12, 2021 at 3:18 PM tapi...@gmail.com
>> wrote:
>>
>>>
>>> func Bar[T []byte|string](s T) bool {
>>> for _, v := range s { // cannot range over s (variable of type T
>>> constrained by []byte|string) (T has no structural type)
>>> if v > 100 {
>>> return true
>>> }
>>> }
>>> return false
>>> }
>>>
>>> The message is quite confusing.
>>>
>>> --
>>> 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/44b5f535-adc8-4049-ba41-638f90becc3cn%40googlegroups.com
>>>
>>> .
>>>
>> --
> 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/abd83194-8198-40e8-ad12-82953f85fba5n%40googlegroups.com
>
> .
>
--
>>> 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/42054eee-a9df-40d1-b148-4e5ead89ee0cn%40googlegroups.com
>>>
>>> .
>>>
>>
--
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/CAHbs%3DNb133_JRg%2BJCYsdSbZN24OM_pA1S92zY%2BKACEF8MC%3Da6g%40mail.gmail.com.
Re: [go-nuts] Is this a known problem?
Oh, sorry, I just re-read. Your example still requires `range` to return
distinct types, so that probably shouldn't work.
On Fri, Nov 12, 2021 at 4:52 PM Axel Wagner
wrote:
> The error message gives you a reason - there is no single underlying type.
> This works:
>
> type B []byte
> func Bar[T []byte|B](s T) {
> for range s {}
> }
>
> But yes, your example arguably should be made to work eventually. I would
> suggest filing an issue about that.
>
> On Fri, Nov 12, 2021 at 4:47 PM tapi...@gmail.com
> wrote:
>
>> This one doesn't compile either.
>> So the range operation doesn't support values of parameter types?
>>
>> type MyByte byte
>>
>> func Bar[T []byte|[]MyByte](s T) {
>> for range s {} // cannot range over s (variable of type T constrained
>> by []byte|[]MyByte) (type set has no single underlying
>> }
>>
>> On Friday, November 12, 2021 at 11:40:53 PM UTC+8
>> axel.wa...@googlemail.com wrote:
>>
>>> On Fri, Nov 12, 2021 at 4:29 PM tapi...@gmail.com
>>> wrote:
>>>
On Friday, November 12, 2021 at 11:10:17 PM UTC+8
axel.wa...@googlemail.com wrote:
> `range s` works differently for string and []byte. In the former case
> it iterates over utf8-encoded unicode codepoints, in the latter it
> iterates
> over bytes.
>
It is true, but why it matters here?
>>>
>>> Because it makes `range` different operations for the purposes of
>>> determining the allowed operations on a type-parameter.
>>>
>>>
>
> On Fri, Nov 12, 2021 at 3:18 PM tapi...@gmail.com
> wrote:
>
>>
>> func Bar[T []byte|string](s T) bool {
>> for _, v := range s { // cannot range over s (variable of type T
>> constrained by []byte|string) (T has no structural type)
>> if v > 100 {
>> return true
>> }
>> }
>> return false
>> }
>>
>> The message is quite confusing.
>>
>> --
>> 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/44b5f535-adc8-4049-ba41-638f90becc3cn%40googlegroups.com
>>
>> .
>>
> --
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/abd83194-8198-40e8-ad12-82953f85fba5n%40googlegroups.com
.
>>> --
>> 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/42054eee-a9df-40d1-b148-4e5ead89ee0cn%40googlegroups.com
>>
>> .
>>
>
--
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/CAEkBMfF-N7%3DApH7bt8WfFeQ99rL8wh%3D0PP1YL4rWVsGk7_TQJQ%40mail.gmail.com.
Re: [go-nuts] Is this a known problem?
The error message gives you a reason - there is no single underlying type.
This works:
type B []byte
func Bar[T []byte|B](s T) {
for range s {}
}
But yes, your example arguably should be made to work eventually. I would
suggest filing an issue about that.
On Fri, Nov 12, 2021 at 4:47 PM tapi...@gmail.com
wrote:
> This one doesn't compile either.
> So the range operation doesn't support values of parameter types?
>
> type MyByte byte
>
> func Bar[T []byte|[]MyByte](s T) {
> for range s {} // cannot range over s (variable of type T constrained
> by []byte|[]MyByte) (type set has no single underlying
> }
>
> On Friday, November 12, 2021 at 11:40:53 PM UTC+8
> axel.wa...@googlemail.com wrote:
>
>> On Fri, Nov 12, 2021 at 4:29 PM tapi...@gmail.com
>> wrote:
>>
>>> On Friday, November 12, 2021 at 11:10:17 PM UTC+8
>>> axel.wa...@googlemail.com wrote:
>>>
`range s` works differently for string and []byte. In the former case
it iterates over utf8-encoded unicode codepoints, in the latter it iterates
over bytes.
>>>
>>> It is true, but why it matters here?
>>>
>>
>> Because it makes `range` different operations for the purposes of
>> determining the allowed operations on a type-parameter.
>>
>>
>>>
>>>
On Fri, Nov 12, 2021 at 3:18 PM tapi...@gmail.com
wrote:
>
> func Bar[T []byte|string](s T) bool {
> for _, v := range s { // cannot range over s (variable of type T
> constrained by []byte|string) (T has no structural type)
> if v > 100 {
> return true
> }
> }
> return false
> }
>
> The message is quite confusing.
>
> --
> 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/44b5f535-adc8-4049-ba41-638f90becc3cn%40googlegroups.com
>
> .
>
--
>>> 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/abd83194-8198-40e8-ad12-82953f85fba5n%40googlegroups.com
>>>
>>> .
>>>
>> --
> 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/42054eee-a9df-40d1-b148-4e5ead89ee0cn%40googlegroups.com
>
> .
>
--
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/CAEkBMfGfo42fR7_JONduVEPX6yA5-A7-beMutne6hWoLLFK_2g%40mail.gmail.com.
Re: [go-nuts] Is this a known problem?
This one doesn't compile either.
So the range operation doesn't support values of parameter types?
type MyByte byte
func Bar[T []byte|[]MyByte](s T) {
for range s {} // cannot range over s (variable of type T constrained
by []byte|[]MyByte) (type set has no single underlying
}
On Friday, November 12, 2021 at 11:40:53 PM UTC+8 axel.wa...@googlemail.com
wrote:
> On Fri, Nov 12, 2021 at 4:29 PM tapi...@gmail.com
> wrote:
>
>> On Friday, November 12, 2021 at 11:10:17 PM UTC+8
>> axel.wa...@googlemail.com wrote:
>>
>>> `range s` works differently for string and []byte. In the former case it
>>> iterates over utf8-encoded unicode codepoints, in the latter it iterates
>>> over bytes.
>>>
>>
>> It is true, but why it matters here?
>>
>
> Because it makes `range` different operations for the purposes of
> determining the allowed operations on a type-parameter.
>
>
>>
>>
>>>
>>> On Fri, Nov 12, 2021 at 3:18 PM tapi...@gmail.com
>>> wrote:
>>>
func Bar[T []byte|string](s T) bool {
for _, v := range s { // cannot range over s (variable of type T
constrained by []byte|string) (T has no structural type)
if v > 100 {
return true
}
}
return false
}
The message is quite confusing.
--
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/44b5f535-adc8-4049-ba41-638f90becc3cn%40googlegroups.com
.
>>> --
>> 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/abd83194-8198-40e8-ad12-82953f85fba5n%40googlegroups.com
>>
>>
>> .
>>
>
--
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/42054eee-a9df-40d1-b148-4e5ead89ee0cn%40googlegroups.com.
Re: [go-nuts] Is this a known problem?
On Fri, Nov 12, 2021 at 4:29 PM tapi...@gmail.com
wrote:
> On Friday, November 12, 2021 at 11:10:17 PM UTC+8
> axel.wa...@googlemail.com wrote:
>
>> `range s` works differently for string and []byte. In the former case it
>> iterates over utf8-encoded unicode codepoints, in the latter it iterates
>> over bytes.
>>
>
> It is true, but why it matters here?
>
Because it makes `range` different operations for the purposes of
determining the allowed operations on a type-parameter.
>
>
>>
>> On Fri, Nov 12, 2021 at 3:18 PM tapi...@gmail.com
>> wrote:
>>
>>>
>>> func Bar[T []byte|string](s T) bool {
>>> for _, v := range s { // cannot range over s (variable of type T
>>> constrained by []byte|string) (T has no structural type)
>>> if v > 100 {
>>> return true
>>> }
>>> }
>>> return false
>>> }
>>>
>>> The message is quite confusing.
>>>
>>> --
>>> 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/44b5f535-adc8-4049-ba41-638f90becc3cn%40googlegroups.com
>>>
>>> .
>>>
>> --
> 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/abd83194-8198-40e8-ad12-82953f85fba5n%40googlegroups.com
>
> .
>
--
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/CAEkBMfGoMM7ofPimitGfEtp%2BhsT0ifnDHdLae7r6T0gJ_V46Ww%40mail.gmail.com.
Re: [go-nuts] Is this a known problem?
On Friday, November 12, 2021 at 11:10:17 PM UTC+8 axel.wa...@googlemail.com
wrote:
> `range s` works differently for string and []byte. In the former case it
> iterates over utf8-encoded unicode codepoints, in the latter it iterates
> over bytes.
>
It is true, but why it matters here?
>
> On Fri, Nov 12, 2021 at 3:18 PM tapi...@gmail.com
> wrote:
>
>>
>> func Bar[T []byte|string](s T) bool {
>> for _, v := range s { // cannot range over s (variable of type T
>> constrained by []byte|string) (T has no structural type)
>> if v > 100 {
>> return true
>> }
>> }
>> return false
>> }
>>
>> The message is quite confusing.
>>
>> --
>> 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/44b5f535-adc8-4049-ba41-638f90becc3cn%40googlegroups.com
>>
>>
>> .
>>
>
--
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/abd83194-8198-40e8-ad12-82953f85fba5n%40googlegroups.com.
Re: [go-nuts] How the scopes of type parameters are defined?
It's hard to say exactly, at this point, because the spec-changes for
generics are not yet written.
I don't think the behavior you observe is bad, but we'll have to see how we
can put it into the spec.
Currently, function parameters are scoped to the function body. Uniqueness
is litigated via a separate rule. That explains why `func(x int) { var x
string }` complains about a re-declaration - both `x` are scoped to the
function body. With `func(x int) { { var x string } }`, the
variable-declaration is scoped to the inner block, while the parameter is
scoped to the body itself. This difference explains why your last example
compiles, but the previous doesn't.
The solution for type-parameters will probably be similar - they get scoped
to the function body (or type-literal), but get some extra rules for how
they are resolved inside the function signature itself. That could
relatively easily explain all the behavior you observe.
On Fri, Nov 12, 2021 at 2:55 PM T L wrote:
> This one compiles okay:
>
> func Bar2[T any](x T) T {
>{
> var T = x // T redeclared in this block
> return T
>}
> }
>
> So the parameter type is declared at the local top block?
>
>
> On Fri, Nov 12, 2021 at 9:43 PM T L wrote:
>
>> It is strange that my recent comments are deleted automatically if they
>> are posted from the web interface.
>> But now from the email interface.
>>
>> On Fri, Nov 12, 2021 at 9:40 PM T L wrote:
>>
>>> Are the followings also intended?
>>>
>>> func Foo[T any](T T) T { // (the 2nd) T redeclared in this block
>>>return T // T (type) is not an expression
>>> }
>>>
>>> func Bar[T any](x T) T {
>>>var T = x // T redeclared in this block
>>>return T
>>> }
>>>
>>> On Fri, Nov 12, 2021 at 6:03 PM Axel Wagner <
>>> axel.wagner...@googlemail.com> wrote:
>>>
On Fri, Nov 12, 2021 at 10:54 AM tapi...@gmail.com
wrote:
>
>
> On Friday, November 12, 2021 at 5:33:19 PM UTC+8
> axel.wa...@googlemail.com wrote:
>
>> I suspect this issue is hard/impossible to avoid, because it must be
>> possible to self- and mutually reference type-parameters, in a way that
>> it's not for normal parameters, to allow to write something like
>>
>> type Equaler[T any] interface {
>> Equal(T) bool
>> }
>> func Eq[T Equaler[T]](a, b T) bool {
>> return a.Equal(b)
>> }
>>
>
> I don't see the same problem here. "T" and "Equaler" are two different
> identifiers.
>
But T and T are not.
The point I was making is that type-parameters must inherently be
scoped in a way that makes them visible in the type-list itself, to make
writing code like this possible. This isn't necessary for regular
parameters and it's what makes type-parameter lists special.
I *also* said that it's probably possible to devise rules which would
make this possible, while allowing the example you wrote, just that those
rules would have to be complicated.
>
>
>>
>> or basically any use-case for constraint-type inference.
>>
>> Even if we *could* allow it consistently, the rules for doing that
>> would likely be pretty complex. Better to take the relatively minor hit
>> of
>> disallowing this overloading (you can always use different names for the
>> type-parameters, if they conflict with the constraint you want to use)
>> than
>> to take the hit of complex scoping rules with lots of exceptions.
>>
>> On Fri, Nov 12, 2021 at 9:48 AM tapi...@gmail.com
>> wrote:
>>
>>> I expect the following code compilers okay, but it doesn't.
>>> It looks All the three "I" in the Bar function declaration are
>>> viewed as the type parameter, whereas the second one is
>>> expected as the constraint I (at least by me).
>>>
>>> package main
>>>
>>> type I interface { M() }
>>>
>>> func Foo(i I) {
>>> i.M()
>>> }
>>>
>>> func Bar[I I](i I) { // cannot use a type parameter as constraint
>>> i.M()
>>> }
>>>
>>> func main() {}
>>>
>>> --
>>> 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/9fc66e8e-3f99-4c3a-87f7-ce7c1a705cdcn%40googlegroups.com
>>>
>>> .
>>>
>> --
> 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
Re: [go-nuts] Is this a known problem?
`range s` works differently for string and []byte. In the former case it
iterates over utf8-encoded unicode codepoints, in the latter it iterates
over bytes.
On Fri, Nov 12, 2021 at 3:18 PM tapi...@gmail.com
wrote:
>
> func Bar[T []byte|string](s T) bool {
> for _, v := range s { // cannot range over s (variable of type T
> constrained by []byte|string) (T has no structural type)
> if v > 100 {
> return true
> }
> }
> return false
> }
>
> The message is quite confusing.
>
> --
> 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/44b5f535-adc8-4049-ba41-638f90becc3cn%40googlegroups.com
>
> .
>
--
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/CAEkBMfHKr4m3sAsuCVG0_-AZniF1vDyWU1Umoi3sO1Jujq1ZTA%40mail.gmail.com.
[go-nuts] Is this a known problem?
func Bar[T []byte|string](s T) bool {
for _, v := range s { // cannot range over s (variable of type T
constrained by []byte|string) (T has no structural type)
if v > 100 {
return true
}
}
return false
}
The message is quite confusing.
--
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/44b5f535-adc8-4049-ba41-638f90becc3cn%40googlegroups.com.
Re: [go-nuts] How the scopes of type parameters are defined?
This one compiles okay:
func Bar2[T any](x T) T {
{
var T = x // T redeclared in this block
return T
}
}
So the parameter type is declared at the local top block?
On Fri, Nov 12, 2021 at 9:43 PM T L wrote:
> It is strange that my recent comments are deleted automatically if they
> are posted from the web interface.
> But now from the email interface.
>
> On Fri, Nov 12, 2021 at 9:40 PM T L wrote:
>
>> Are the followings also intended?
>>
>> func Foo[T any](T T) T { // (the 2nd) T redeclared in this block
>>return T // T (type) is not an expression
>> }
>>
>> func Bar[T any](x T) T {
>>var T = x // T redeclared in this block
>>return T
>> }
>>
>> On Fri, Nov 12, 2021 at 6:03 PM Axel Wagner <
>> axel.wagner...@googlemail.com> wrote:
>>
>>>
>>>
>>> On Fri, Nov 12, 2021 at 10:54 AM tapi...@gmail.com
>>> wrote:
>>>
On Friday, November 12, 2021 at 5:33:19 PM UTC+8
axel.wa...@googlemail.com wrote:
> I suspect this issue is hard/impossible to avoid, because it must be
> possible to self- and mutually reference type-parameters, in a way that
> it's not for normal parameters, to allow to write something like
>
> type Equaler[T any] interface {
> Equal(T) bool
> }
> func Eq[T Equaler[T]](a, b T) bool {
> return a.Equal(b)
> }
>
I don't see the same problem here. "T" and "Equaler" are two different
identifiers.
>>>
>>> But T and T are not.
>>>
>>> The point I was making is that type-parameters must inherently be scoped
>>> in a way that makes them visible in the type-list itself, to make writing
>>> code like this possible. This isn't necessary for regular parameters and
>>> it's what makes type-parameter lists special.
>>>
>>> I *also* said that it's probably possible to devise rules which would
>>> make this possible, while allowing the example you wrote, just that those
>>> rules would have to be complicated.
>>>
>>>
>
> or basically any use-case for constraint-type inference.
>
> Even if we *could* allow it consistently, the rules for doing that
> would likely be pretty complex. Better to take the relatively minor hit of
> disallowing this overloading (you can always use different names for the
> type-parameters, if they conflict with the constraint you want to use)
> than
> to take the hit of complex scoping rules with lots of exceptions.
>
> On Fri, Nov 12, 2021 at 9:48 AM tapi...@gmail.com
> wrote:
>
>> I expect the following code compilers okay, but it doesn't.
>> It looks All the three "I" in the Bar function declaration are
>> viewed as the type parameter, whereas the second one is
>> expected as the constraint I (at least by me).
>>
>> package main
>>
>> type I interface { M() }
>>
>> func Foo(i I) {
>> i.M()
>> }
>>
>> func Bar[I I](i I) { // cannot use a type parameter as constraint
>> i.M()
>> }
>>
>> func main() {}
>>
>> --
>> 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/9fc66e8e-3f99-4c3a-87f7-ce7c1a705cdcn%40googlegroups.com
>>
>> .
>>
> --
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/a4ffdc09-02cf-47af-96fc-3ebde3fc5d10n%40googlegroups.com
.
>>>
--
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/CAHbs%3DNZVnhK2fV2R2NbtXvfsyV%3DfP1ToD0SoSBhf9%3Dr0d19gPg%40mail.gmail.com.
Re: [go-nuts] How the scopes of type parameters are defined?
It is strange that my recent comments are deleted automatically if they are
posted from the web interface.
But now from the email interface.
On Fri, Nov 12, 2021 at 9:40 PM T L wrote:
> Are the followings also intended?
>
> func Foo[T any](T T) T { // (the 2nd) T redeclared in this block
>return T // T (type) is not an expression
> }
>
> func Bar[T any](x T) T {
>var T = x // T redeclared in this block
>return T
> }
>
> On Fri, Nov 12, 2021 at 6:03 PM Axel Wagner
> wrote:
>
>>
>>
>> On Fri, Nov 12, 2021 at 10:54 AM tapi...@gmail.com
>> wrote:
>>
>>>
>>>
>>> On Friday, November 12, 2021 at 5:33:19 PM UTC+8
>>> axel.wa...@googlemail.com wrote:
>>>
I suspect this issue is hard/impossible to avoid, because it must be
possible to self- and mutually reference type-parameters, in a way that
it's not for normal parameters, to allow to write something like
type Equaler[T any] interface {
Equal(T) bool
}
func Eq[T Equaler[T]](a, b T) bool {
return a.Equal(b)
}
>>>
>>> I don't see the same problem here. "T" and "Equaler" are two different
>>> identifiers.
>>>
>>
>> But T and T are not.
>>
>> The point I was making is that type-parameters must inherently be scoped
>> in a way that makes them visible in the type-list itself, to make writing
>> code like this possible. This isn't necessary for regular parameters and
>> it's what makes type-parameter lists special.
>>
>> I *also* said that it's probably possible to devise rules which would
>> make this possible, while allowing the example you wrote, just that those
>> rules would have to be complicated.
>>
>>
>>>
>>>
or basically any use-case for constraint-type inference.
Even if we *could* allow it consistently, the rules for doing that
would likely be pretty complex. Better to take the relatively minor hit of
disallowing this overloading (you can always use different names for the
type-parameters, if they conflict with the constraint you want to use) than
to take the hit of complex scoping rules with lots of exceptions.
On Fri, Nov 12, 2021 at 9:48 AM tapi...@gmail.com
wrote:
> I expect the following code compilers okay, but it doesn't.
> It looks All the three "I" in the Bar function declaration are
> viewed as the type parameter, whereas the second one is
> expected as the constraint I (at least by me).
>
> package main
>
> type I interface { M() }
>
> func Foo(i I) {
> i.M()
> }
>
> func Bar[I I](i I) { // cannot use a type parameter as constraint
> i.M()
> }
>
> func main() {}
>
> --
> 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/9fc66e8e-3f99-4c3a-87f7-ce7c1a705cdcn%40googlegroups.com
>
> .
>
--
>>> 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/a4ffdc09-02cf-47af-96fc-3ebde3fc5d10n%40googlegroups.com
>>>
>>> .
>>>
>>
--
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/CAHbs%3DNYm6EmC3G2fV77zUh7%3D6xUDj2fhuMAYO7iV2bTD6bkOfw%40mail.gmail.com.
Re: [go-nuts] How the scopes of type parameters are defined?
Are the followings also intended?
func Foo[T any](T T) T { // (the 2nd) T redeclared in this block
return T // T (type) is not an expression
}
func Bar[T any](x T) T {
var T = x // T redeclared in this block
return T
}
On Fri, Nov 12, 2021 at 6:03 PM Axel Wagner
wrote:
>
>
> On Fri, Nov 12, 2021 at 10:54 AM tapi...@gmail.com
> wrote:
>
>>
>>
>> On Friday, November 12, 2021 at 5:33:19 PM UTC+8
>> axel.wa...@googlemail.com wrote:
>>
>>> I suspect this issue is hard/impossible to avoid, because it must be
>>> possible to self- and mutually reference type-parameters, in a way that
>>> it's not for normal parameters, to allow to write something like
>>>
>>> type Equaler[T any] interface {
>>> Equal(T) bool
>>> }
>>> func Eq[T Equaler[T]](a, b T) bool {
>>> return a.Equal(b)
>>> }
>>>
>>
>> I don't see the same problem here. "T" and "Equaler" are two different
>> identifiers.
>>
>
> But T and T are not.
>
> The point I was making is that type-parameters must inherently be scoped
> in a way that makes them visible in the type-list itself, to make writing
> code like this possible. This isn't necessary for regular parameters and
> it's what makes type-parameter lists special.
>
> I *also* said that it's probably possible to devise rules which would make
> this possible, while allowing the example you wrote, just that those rules
> would have to be complicated.
>
>
>>
>>
>>>
>>> or basically any use-case for constraint-type inference.
>>>
>>> Even if we *could* allow it consistently, the rules for doing that would
>>> likely be pretty complex. Better to take the relatively minor hit of
>>> disallowing this overloading (you can always use different names for the
>>> type-parameters, if they conflict with the constraint you want to use) than
>>> to take the hit of complex scoping rules with lots of exceptions.
>>>
>>> On Fri, Nov 12, 2021 at 9:48 AM tapi...@gmail.com
>>> wrote:
>>>
I expect the following code compilers okay, but it doesn't.
It looks All the three "I" in the Bar function declaration are
viewed as the type parameter, whereas the second one is
expected as the constraint I (at least by me).
package main
type I interface { M() }
func Foo(i I) {
i.M()
}
func Bar[I I](i I) { // cannot use a type parameter as constraint
i.M()
}
func main() {}
--
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/9fc66e8e-3f99-4c3a-87f7-ce7c1a705cdcn%40googlegroups.com
.
>>> --
>> 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/a4ffdc09-02cf-47af-96fc-3ebde3fc5d10n%40googlegroups.com
>>
>> .
>>
>
--
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/CAHbs%3DNYn-r01bMXTNU2qEtYxxo2pBtL%2BgURYkNrfJH%2BRUq%3DLSA%40mail.gmail.com.
Re: [go-nuts] Which error handling pattern do you prefer?
I tend to use errX (X is adapted according to context) for function scoped
errors, and err for block scoped errors
func MyFunc() error {
> v, errDS := doSomething()
> ...
> errDA := doAnotherthing()
> }
>
if err := doAnotherthing(); err != nil {
> return err
> }
>
That way you don't shadow errors.
>
--
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/CAF9DLCmR4ZdnVs4A28BSrPcbiHsQ_ufub5cSPjCt2SDy2dA1xA%40mail.gmail.com.
Re: [go-nuts] How the scopes of type parameters are defined?
And FWIW, just to illustrate the expected complexity: We also want these
two declarations to mean the same:
func A[T A]()
func B[T interface{ A }]()
So the rules also need to accommodate that. It gets only more complicated
from there.
On Fri, Nov 12, 2021 at 11:03 AM Axel Wagner
wrote:
>
>
> On Fri, Nov 12, 2021 at 10:54 AM tapi...@gmail.com
> wrote:
>
>>
>>
>> On Friday, November 12, 2021 at 5:33:19 PM UTC+8
>> axel.wa...@googlemail.com wrote:
>>
>>> I suspect this issue is hard/impossible to avoid, because it must be
>>> possible to self- and mutually reference type-parameters, in a way that
>>> it's not for normal parameters, to allow to write something like
>>>
>>> type Equaler[T any] interface {
>>> Equal(T) bool
>>> }
>>> func Eq[T Equaler[T]](a, b T) bool {
>>> return a.Equal(b)
>>> }
>>>
>>
>> I don't see the same problem here. "T" and "Equaler" are two different
>> identifiers.
>>
>
> But T and T are not.
>
> The point I was making is that type-parameters must inherently be scoped
> in a way that makes them visible in the type-list itself, to make writing
> code like this possible. This isn't necessary for regular parameters and
> it's what makes type-parameter lists special.
>
> I *also* said that it's probably possible to devise rules which would make
> this possible, while allowing the example you wrote, just that those rules
> would have to be complicated.
>
>
>>
>>
>>>
>>> or basically any use-case for constraint-type inference.
>>>
>>> Even if we *could* allow it consistently, the rules for doing that would
>>> likely be pretty complex. Better to take the relatively minor hit of
>>> disallowing this overloading (you can always use different names for the
>>> type-parameters, if they conflict with the constraint you want to use) than
>>> to take the hit of complex scoping rules with lots of exceptions.
>>>
>>> On Fri, Nov 12, 2021 at 9:48 AM tapi...@gmail.com
>>> wrote:
>>>
I expect the following code compilers okay, but it doesn't.
It looks All the three "I" in the Bar function declaration are
viewed as the type parameter, whereas the second one is
expected as the constraint I (at least by me).
package main
type I interface { M() }
func Foo(i I) {
i.M()
}
func Bar[I I](i I) { // cannot use a type parameter as constraint
i.M()
}
func main() {}
--
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/9fc66e8e-3f99-4c3a-87f7-ce7c1a705cdcn%40googlegroups.com
.
>>> --
>> 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/a4ffdc09-02cf-47af-96fc-3ebde3fc5d10n%40googlegroups.com
>>
>> .
>>
>
--
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/CAEkBMfHHwjWhB7FZBqjf_g3p2NtAfeivixH1_hVU4aessqS2uw%40mail.gmail.com.
Re: [go-nuts] How the scopes of type parameters are defined?
On Fri, Nov 12, 2021 at 10:54 AM tapi...@gmail.com
wrote:
>
>
> On Friday, November 12, 2021 at 5:33:19 PM UTC+8 axel.wa...@googlemail.com
> wrote:
>
>> I suspect this issue is hard/impossible to avoid, because it must be
>> possible to self- and mutually reference type-parameters, in a way that
>> it's not for normal parameters, to allow to write something like
>>
>> type Equaler[T any] interface {
>> Equal(T) bool
>> }
>> func Eq[T Equaler[T]](a, b T) bool {
>> return a.Equal(b)
>> }
>>
>
> I don't see the same problem here. "T" and "Equaler" are two different
> identifiers.
>
But T and T are not.
The point I was making is that type-parameters must inherently be scoped in
a way that makes them visible in the type-list itself, to make writing code
like this possible. This isn't necessary for regular parameters and it's
what makes type-parameter lists special.
I *also* said that it's probably possible to devise rules which would make
this possible, while allowing the example you wrote, just that those rules
would have to be complicated.
>
>
>>
>> or basically any use-case for constraint-type inference.
>>
>> Even if we *could* allow it consistently, the rules for doing that would
>> likely be pretty complex. Better to take the relatively minor hit of
>> disallowing this overloading (you can always use different names for the
>> type-parameters, if they conflict with the constraint you want to use) than
>> to take the hit of complex scoping rules with lots of exceptions.
>>
>> On Fri, Nov 12, 2021 at 9:48 AM tapi...@gmail.com
>> wrote:
>>
>>> I expect the following code compilers okay, but it doesn't.
>>> It looks All the three "I" in the Bar function declaration are
>>> viewed as the type parameter, whereas the second one is
>>> expected as the constraint I (at least by me).
>>>
>>> package main
>>>
>>> type I interface { M() }
>>>
>>> func Foo(i I) {
>>> i.M()
>>> }
>>>
>>> func Bar[I I](i I) { // cannot use a type parameter as constraint
>>> i.M()
>>> }
>>>
>>> func main() {}
>>>
>>> --
>>> 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/9fc66e8e-3f99-4c3a-87f7-ce7c1a705cdcn%40googlegroups.com
>>>
>>> .
>>>
>> --
> 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/a4ffdc09-02cf-47af-96fc-3ebde3fc5d10n%40googlegroups.com
>
> .
>
--
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/CAEkBMfGe0WAm6K6eBWr23WgqZUhLMqt8F%2BTmsayDf53Uj9s8Jg%40mail.gmail.com.
Re: [go-nuts] How the scopes of type parameters are defined?
On Friday, November 12, 2021 at 5:33:19 PM UTC+8 axel.wa...@googlemail.com
wrote:
> I suspect this issue is hard/impossible to avoid, because it must be
> possible to self- and mutually reference type-parameters, in a way that
> it's not for normal parameters, to allow to write something like
>
> type Equaler[T any] interface {
> Equal(T) bool
> }
> func Eq[T Equaler[T]](a, b T) bool {
> return a.Equal(b)
> }
>
I don't see the same problem here. "T" and "Equaler" are two different
identifiers.
>
> or basically any use-case for constraint-type inference.
>
> Even if we *could* allow it consistently, the rules for doing that would
> likely be pretty complex. Better to take the relatively minor hit of
> disallowing this overloading (you can always use different names for the
> type-parameters, if they conflict with the constraint you want to use) than
> to take the hit of complex scoping rules with lots of exceptions.
>
> On Fri, Nov 12, 2021 at 9:48 AM tapi...@gmail.com
> wrote:
>
>> I expect the following code compilers okay, but it doesn't.
>> It looks All the three "I" in the Bar function declaration are
>> viewed as the type parameter, whereas the second one is
>> expected as the constraint I (at least by me).
>>
>> package main
>>
>> type I interface { M() }
>>
>> func Foo(i I) {
>> i.M()
>> }
>>
>> func Bar[I I](i I) { // cannot use a type parameter as constraint
>> i.M()
>> }
>>
>> func main() {}
>>
>> --
>> 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/9fc66e8e-3f99-4c3a-87f7-ce7c1a705cdcn%40googlegroups.com
>>
>>
>> .
>>
>
--
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/a4ffdc09-02cf-47af-96fc-3ebde3fc5d10n%40googlegroups.com.
Re: [go-nuts] How the scopes of type parameters are defined?
I suspect this issue is hard/impossible to avoid, because it must be
possible to self- and mutually reference type-parameters, in a way that
it's not for normal parameters, to allow to write something like
type Equaler[T any] interface {
Equal(T) bool
}
func Eq[T Equaler[T]](a, b T) bool {
return a.Equal(b)
}
or basically any use-case for constraint-type inference.
Even if we *could* allow it consistently, the rules for doing that would
likely be pretty complex. Better to take the relatively minor hit of
disallowing this overloading (you can always use different names for the
type-parameters, if they conflict with the constraint you want to use) than
to take the hit of complex scoping rules with lots of exceptions.
On Fri, Nov 12, 2021 at 9:48 AM tapi...@gmail.com
wrote:
> I expect the following code compilers okay, but it doesn't.
> It looks All the three "I" in the Bar function declaration are
> viewed as the type parameter, whereas the second one is
> expected as the constraint I (at least by me).
>
> package main
>
> type I interface { M() }
>
> func Foo(i I) {
> i.M()
> }
>
> func Bar[I I](i I) { // cannot use a type parameter as constraint
> i.M()
> }
>
> func main() {}
>
> --
> 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/9fc66e8e-3f99-4c3a-87f7-ce7c1a705cdcn%40googlegroups.com
>
> .
>
--
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/CAEkBMfGj_h1iTSx%2BhFoQC%3DWJm_XeL7-Jf%2BcOmNEc5gT8ZxubNA%40mail.gmail.com.
Re: [go-nuts] Which error handling pattern do you prefer?
`I do find this rather annoying, to the point where I'll stick a "var err
error" at the top of a function rather than have the first assignment be
different to the subsequent ones. `
I think this is a good way. I usually code in this way if there're multiple
error assignments.
If each error assignment statement only return single return value (the
error itself), I code it in one-liner way.
On Friday, November 12, 2021 at 4:53:21 PM UTC+8 Kn wrote:
>
> Oh, I have a typo error, in the second pattern, `err := doAnotherthing()`
> should be `err = doAnotherthing()`.
> On Friday, November 12, 2021 at 4:02:34 PM UTC+8 Brian Candler wrote:
>
>> func MyFunc() error {
>> v, err := doSomething()
>> ...
>> err := doAnotherthing()
>> }
>>
>> That won't compile anyway; the second assignment would have to be
>>
>> err = doAnotherthing()
>>
>> See: https://play.golang.org/p/pvNC7YHI88j
>>
>> I do find this rather annoying, to the point where I'll stick a "var err
>> error" at the top of a function rather than have the first assignment be
>> different to the subsequent ones. And yet, a single assignment is fine if
>> you use the assign-and-test form, since this introduces a new variable
>> which is only scoped to that block:
>>
>> // This is OK
>> if err := doAnotherthing(); err != nil {
>> return err
>> }
>>
>> See: https://play.golang.org/p/4NKmFoX7uj2
>>
>> It is also possible to use named return values and a naked return,
>> although I get the impression this tends to be frowned upon.
>>
>
--
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/714a465e-1581-4c45-ab70-51a9bef4cef2n%40googlegroups.com.
Re: [go-nuts] Which error handling pattern do you prefer?
Oh, I have a typo error, in the second pattern, `err := doAnotherthing()`
should be `err = doAnotherthing()`.
On Friday, November 12, 2021 at 4:02:34 PM UTC+8 Brian Candler wrote:
> func MyFunc() error {
> v, err := doSomething()
> ...
> err := doAnotherthing()
> }
>
> That won't compile anyway; the second assignment would have to be
>
> err = doAnotherthing()
>
> See: https://play.golang.org/p/pvNC7YHI88j
>
> I do find this rather annoying, to the point where I'll stick a "var err
> error" at the top of a function rather than have the first assignment be
> different to the subsequent ones. And yet, a single assignment is fine if
> you use the assign-and-test form, since this introduces a new variable
> which is only scoped to that block:
>
> // This is OK
> if err := doAnotherthing(); err != nil {
> return err
> }
>
> See: https://play.golang.org/p/4NKmFoX7uj2
>
> It is also possible to use named return values and a naked return,
> although I get the impression this tends to be frowned upon.
>
--
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/f3251f3b-fe94-4dba-badb-c422f96dc666n%40googlegroups.com.
[go-nuts] How the scopes of type parameters are defined?
I expect the following code compilers okay, but it doesn't.
It looks All the three "I" in the Bar function declaration are
viewed as the type parameter, whereas the second one is
expected as the constraint I (at least by me).
package main
type I interface { M() }
func Foo(i I) {
i.M()
}
func Bar[I I](i I) { // cannot use a type parameter as constraint
i.M()
}
func main() {}
--
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/9fc66e8e-3f99-4c3a-87f7-ce7c1a705cdcn%40googlegroups.com.
Re: [go-nuts] Which error handling pattern do you prefer?
func MyFunc() error {
v, err := doSomething()
...
err := doAnotherthing()
}
That won't compile anyway; the second assignment would have to be
err = doAnotherthing()
See: https://play.golang.org/p/pvNC7YHI88j
I do find this rather annoying, to the point where I'll stick a "var err
error" at the top of a function rather than have the first assignment be
different to the subsequent ones. And yet, a single assignment is fine if
you use the assign-and-test form, since this introduces a new variable
which is only scoped to that block:
// This is OK
if err := doAnotherthing(); err != nil {
return err
}
See: https://play.golang.org/p/4NKmFoX7uj2
It is also possible to use named return values and a naked return, although
I get the impression this tends to be frowned upon.
--
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/29e1b407-020f-48c6-bab9-7c4db44b038cn%40googlegroups.com.
