[go-nuts] Possible to make base64 pick the decode encoding automatically?
Hi, I have an io.Reader whose content is encoded in base64 with encoding type unknown. Since there shouldn't be any ambiguity between the two, is it possible to make the base64 automatically pick the right one to decode? Currently I have to read everything out to pin down the encoding, which defeats the purpose of using an io.Reader. Is there a solution to this problem? Thanks in advance. -- 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/0ccee37d-319e-41b3-9bfd-3dc46e0fad78n%40googlegroups.com.
Re: [go-nuts] Possible to make base64 pick the decode encoding automatically?
Your translate reader works really well, thanks for sharing it. I have seen code that tried to decode base64 four times in the wild, which led me to posting this, hope something like this could be incorporated into the standard library. On Tuesday, February 2, 2021 at 8:50:08 PM UTC+8 rog wrote: > In case you find it helpful, here's a clone of the base64 command that I > wrote in Go. I did it precisely because I wanted to be able to decode any > encoding scheme interchangeably. > > https://github.com/rogpeppe/misc/blob/master/cmd/base64/base64.go > > I agree that it might be useful to have some of this functionality > available in the standard library. > > cheers, > rog. > > On Tue, 2 Feb 2021 at 09:08, hey...@gmail.com wrote: > >> Hi, >> >> I have an io.Reader whose content is encoded in base64 with encoding type >> unknown. Since there shouldn't be any ambiguity between the two, is it >> possible to make the base64 automatically pick the right one to decode? >> >> Currently I have to read everything out to pin down the encoding, which >> defeats the purpose of using an io.Reader. >> >> Is there a solution to this problem? >> >> Thanks in advance. >> >> >> -- >> 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/0ccee37d-319e-41b3-9bfd-3dc46e0fad78n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/golang-nuts/0ccee37d-319e-41b3-9bfd-3dc46e0fad78n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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/15c0911e-cf08-48e2-b979-054ee7525d97n%40googlegroups.com.
Re: [go-nuts] Possible to make base64 pick the decode encoding automatically?
_, so it's >>>> easy >>>> to tell which is used and just accept either (and padding can be viewed as >>>> optional during decoding anyway). >>>> >>>> On Tue, Feb 2, 2021 at 2:37 PM Robert Engels >>>> wrote: >>>> >>>>> Base64 is always ASCII. The encoded data may be in an arbitrary >>>>> format. You need to pass additional metadata or try and detect its >>>>> encoding. >>>>> >>>>> On Feb 2, 2021, at 6:50 AM, roger peppe wrote: >>>>> >>>>> >>>>> In case you find it helpful, here's a clone of the base64 command that >>>>> I wrote in Go. I did it precisely because I wanted to be able to decode >>>>> any >>>>> encoding scheme interchangeably. >>>>> >>>>> https://github.com/rogpeppe/misc/blob/master/cmd/base64/base64.go >>>>> >>>>> I agree that it might be useful to have some of this functionality >>>>> available in the standard library. >>>>> >>>>> cheers, >>>>> rog. >>>>> >>>>> On Tue, 2 Feb 2021 at 09:08, hey...@gmail.com >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I have an io.Reader whose content is encoded in base64 with encoding >>>>>> type unknown. Since there shouldn't be any ambiguity between the two, is >>>>>> it >>>>>> possible to make the base64 automatically pick the right one to decode? >>>>>> >>>>>> Currently I have to read everything out to pin down the encoding, >>>>>> which defeats the purpose of using an io.Reader. >>>>>> >>>>>> Is there a solution to this problem? >>>>>> >>>>>> Thanks in advance. >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> 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/0ccee37d-319e-41b3-9bfd-3dc46e0fad78n%40googlegroups.com >>>>>> >>>>>> <https://groups.google.com/d/msgid/golang-nuts/0ccee37d-319e-41b3-9bfd-3dc46e0fad78n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> >>>>> -- >>>>> 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/CAJhgacjkUUSr-dOPFU-W4vG_AXZRY_dYYe2ti-iPuu_XUL%2BNVw%40mail.gmail.com >>>>> >>>>> <https://groups.google.com/d/msgid/golang-nuts/CAJhgacjkUUSr-dOPFU-W4vG_AXZRY_dYYe2ti-iPuu_XUL%2BNVw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>>> >>>>> -- >>>>> 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/CF76EF37-6F82-42FF-B4D6-4B9FC02F25FC%40ix.netcom.com >>>>> >>>>> <https://groups.google.com/d/msgid/golang-nuts/CF76EF37-6F82-42FF-B4D6-4B9FC02F25FC%40ix.netcom.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> >>> -- >>> 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/44621cb2-fae7-4f40-9e50-35b157f4e838n%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/golang-nuts/44621cb2-fae7-4f40-9e50-35b157f4e838n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> >> -- >> 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/CAEkBMfGGkOX9HzF6e178Cu6BD9Hg4x5LT7AutHkUDPvyK%2BFmYg%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/golang-nuts/CAEkBMfGGkOX9HzF6e178Cu6BD9Hg4x5LT7AutHkUDPvyK%2BFmYg%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> > -- > 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/CAEkBMfGwDKwoi4TisXPwi0-85%3D_yOqY1AOBw%3DCnH%3D7E4jhJuBg%40mail.gmail.com > > <https://groups.google.com/d/msgid/golang-nuts/CAEkBMfGwDKwoi4TisXPwi0-85%3D_yOqY1AOBw%3DCnH%3D7E4jhJuBg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > > -- 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/5963b370-e82f-4f50-9d3a-037f3899b5e8n%40googlegroups.com.
[go-nuts] Possible to reuse std/net logic for a Tun device?
Hi, I'm trying to write a Tun device for linux. I learned a lot from github.com/songgao/water and wireguard-go on how to create a tun interface. However, I'm not sure how to leverage std/net to read from and write to it. water seems to leave the read & write part to its users, and wireguard-go seems to parse/generate packets by its own logic. I wonder if given a linux fd, is it possible to leverage std/net to read from and write to the corresponding Tun device? Regards, Glen -- 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/cd05531b-e047-440b-88ae-c57e00300d0cn%40googlegroups.com.
[go-nuts] What's go's convention for specifying the equivolent of configure --prefix?
I'm writing a command line program in go, and it needs to access some predefined external files like /usr/lib/name/file. What would be a good way to allow specify the constant path in compile time? I see two options: 1. go generate 2. -ldflags="-X 'main.Path=..." Both seem to be flawed. For #1, the blog clearly stated that it's designed for package author, and not for clients (and go generate doesn't support passing arguments to //go:generate anyways). For #2, the path can't be a constant. Is there a convention on how this problem should be solved or external paths should always be passed in as arguments in go? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/e5029b93-a3d9-4256-ab1c-a83d3b35c579n%40googlegroups.com.
Re: [go-nuts] What's go's convention for specifying the equivolent of configure --prefix?
@Nick @Brian Somehow I missed your replies. Using a Makefile makes sense. And thanks for bringing embed to my attention. I never knew it exists. Sounds like it can solve my problem. Thanks a lot. On Thursday, December 1, 2022 at 6:32:58 PM UTC+8 Nick wrote: > On Thu, Dec 01, 2022 at 06:21:37PM +0800, Glen Huang wrote: > > Const is the ideal choice, but how do users of my program specify the > path when > > they compile it? > > I don't think this is something for which there is a "canonical Go > way", so I'd say something like a tiny makefile that sets the path > with the PREFIX environment variable, passing that to -ldflags as > you suggested. > > > Using var loses the guarantee that the path won’t be changed, and the go > > compiler can no longer optimize as much I presume? > > I don't think it being var rather than const is going to be an > optimization bottleneck. But if it really was important, then you > could use a makefile to insert / overwrite a line with sed or > similar, keeping some sensible default working for users who > eschewed the makefile and just used 'go install' or whatever. > -- 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/b120021e-17c3-4cae-8f94-d3d67570713an%40googlegroups.com.
[go-nuts] Why this simple sorting code doesn't work?
Hi,
I have this very simple sorting code:
s := make([]int, 0, 100)
for i := 1; i <= 20; i++ {
s = append(s, i)
}
sort.Slice(s, func(i, j int) bool { return i > j })
log.Print(s)
I expect it to print numbers in reverse order, since items with larger
index numbers should be at the front. However, at lease in go1.19.3, it
prints
[9 1 8 5 16 3 20 2 10 7 12 13 14 15 6 4 19 18 17 11]
I guess I must have misunderstood how the sort package works, but rereading
sort's doc multiple time doesn't help answer the question.
Could anyone shed some light?
--
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/245f2ca6-b325-4f71-bead-2d9fb078eae7n%40googlegroups.com.
[go-nuts] Re: Why this simple sorting code doesn't work?
Thanks for the quick reply.
But that seems to compare values. I'd like to compare index numbers. The
fact that original values follow index number order is a coincidence.
> I think it'd be recommended to look at the generics slices package, which
also has a sort
Do you mean golang.org/x/exp/slices? That also seems to only compare values.
On Wednesday, December 7, 2022 at 10:45:33 AM UTC+8 harr...@spu.edu wrote:
> Subtly:
> return s[i] > s[j]
>
> Is the right sort func
>
> I think it'd be recommended to look at the generics slices package, which
> also has a sort
> On Tuesday, December 6, 2022 at 6:39:29 PM UTC-8 hey...@gmail.com wrote:
>
>> Hi,
>>
>> I have this very simple sorting code:
>>
>> s := make([]int, 0, 100)
>> for i := 1; i <= 20; i++ {
>> s = append(s, i)
>> }
>> sort.Slice(s, func(i, j int) bool { return i > j })
>> log.Print(s)
>>
>> I expect it to print numbers in reverse order, since items with larger
>> index numbers should be at the front. However, at lease in go1.19.3, it
>> prints
>>
>> [9 1 8 5 16 3 20 2 10 7 12 13 14 15 6 4 19 18 17 11]
>>
>> I guess I must have misunderstood how the sort package works, but
>> rereading sort's doc multiple time doesn't help answer the question.
>>
>> Could anyone shed some light?
>>
>
--
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/051d35c0-4a9a-430e-94d0-604944ce1ae6n%40googlegroups.com.
Re: [go-nuts] Re: Why this simple sorting code doesn't work?
I do want to compare indexes. Is that something possible to do?
In my real code I have other criteria to compare the slice items, but if
they tie, I want to use the reverse of their original order.
I expect `return i > j` to put items with larger index numbers at the
front, why that doesn't seem to be the case?
On Wednesday, December 7, 2022 at 11:13:12 AM UTC+8 eric.h...@gmail.com
wrote:
> sort.Slice(s, func(i, j int) bool { return i > j })
>
> You are comparing the indexes and not the values
>
> -Eric
> http://www.google.com/profiles/eric.hubbard
>
>
> On Tue, Dec 6, 2022 at 6:45 PM Andrew Harris wrote:
>
>> Subtly:
>> return s[i] > s[j]
>>
>> Is the right sort func
>>
>> I think it'd be recommended to look at the generics slices package, which
>> also has a sort
>> On Tuesday, December 6, 2022 at 6:39:29 PM UTC-8 hey...@gmail.com wrote:
>>
>>> Hi,
>>>
>>> I have this very simple sorting code:
>>>
>>> s := make([]int, 0, 100)
>>> for i := 1; i <= 20; i++ {
>>> s = append(s, i)
>>> }
>>> sort.Slice(s, func(i, j int) bool { return i > j })
>>> log.Print(s)
>>>
>>> I expect it to print numbers in reverse order, since items with larger
>>> index numbers should be at the front. However, at lease in go1.19.3, it
>>> prints
>>>
>>> [9 1 8 5 16 3 20 2 10 7 12 13 14 15 6 4 19 18 17 11]
>>>
>>> I guess I must have misunderstood how the sort package works, but
>>> rereading sort's doc multiple time doesn't help answer the question.
>>>
>>> Could anyone shed some light?
>>>
>> --
>> 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/47074e6b-b1f2-447e-b7aa-645b9a504913n%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/golang-nuts/47074e6b-b1f2-447e-b7aa-645b9a504913n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>
--
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/94a5c85a-f81f-4d11-9aa0-0f8d85efc641n%40googlegroups.com.
[go-nuts] Re: Why this simple sorting code doesn't work?
> sorts defined by an ordering function purely dependent on the value of
the element
Hmm, I thought the function was agnostic to what really get compared? If it
offers two index numbers, and the return value says the one with larger
index number should be at the front, shouldn't the sort function simply do
that, since during the sorting, the passed index number should be stable?
On Wednesday, December 7, 2022 at 11:14:37 AM UTC+8 harr...@spu.edu wrote:
> Oh, to reverse by index ... I think this doesn't quite fit in the idea of
> sorts defined by an ordering function purely dependent on the value of the
> element.
>
> I think there may have been a feature request
> <https://github.com/golang/go/issues/47988> for a `slices.Reverse`
> function in golang.org/x/exp/slices - I'm not sure what the status or
> reasoning is on this. FWIW it's not the only approach that might make sense
> for traversing a slice in reverse order, and it can be naive when working
> with e.g. bytes holding utf8.
>
> I think this works but I haven't really thought about edge cases...
>
> `reverse(&s)`
>
> func reverse[T any](s *[]T) {
> z := len(*s)
> for a := 0; a < len(*s)/2; a++ {
> (*s)[a], (*s)[z-a-1] = (*s)[z-a-1], (*s)[a]
> }
> }
>
> On Tuesday, December 6, 2022 at 6:54:38 PM UTC-8 hey...@gmail.com wrote:
>
>> Thanks for the quick reply.
>>
>> But that seems to compare values. I'd like to compare index numbers. The
>> fact that original values follow index number order is a coincidence.
>>
>> > I think it'd be recommended to look at the generics slices package,
>> which also has a sort
>>
>> Do you mean golang.org/x/exp/slices? That also seems to only compare
>> values.
>>
>>
>> On Wednesday, December 7, 2022 at 10:45:33 AM UTC+8 harr...@spu.edu
>> wrote:
>>
>>> Subtly:
>>> return s[i] > s[j]
>>>
>>> Is the right sort func
>>>
>>> I think it'd be recommended to look at the generics slices package,
>>> which also has a sort
>>> On Tuesday, December 6, 2022 at 6:39:29 PM UTC-8 hey...@gmail.com wrote:
>>>
>>>> Hi,
>>>>
>>>> I have this very simple sorting code:
>>>>
>>>> s := make([]int, 0, 100)
>>>> for i := 1; i <= 20; i++ {
>>>> s = append(s, i)
>>>> }
>>>> sort.Slice(s, func(i, j int) bool { return i > j })
>>>> log.Print(s)
>>>>
>>>> I expect it to print numbers in reverse order, since items with larger
>>>> index numbers should be at the front. However, at lease in go1.19.3, it
>>>> prints
>>>>
>>>> [9 1 8 5 16 3 20 2 10 7 12 13 14 15 6 4 19 18 17 11]
>>>>
>>>> I guess I must have misunderstood how the sort package works, but
>>>> rereading sort's doc multiple time doesn't help answer the question.
>>>>
>>>> Could anyone shed some light?
>>>>
>>>
--
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/5fb85879-b356-4d6d-9645-778d3e7c549an%40googlegroups.com.
[go-nuts] Re: Why this simple sorting code doesn't work?
Reversing and then using the stable sort sounds like an elegant solution.
Thanks!
@Robert
I totally missed the indexes could refer to swapped items. I somehow had
the impression that go would memorize the returned order and swap them in
one go. This explains it. Thanks a lot.
On Wednesday, December 7, 2022 at 12:07:48 PM UTC+8 harr...@spu.edu wrote:
> > In my real code I have other criteria to compare the slice items, but if
> they tie, I want to use the reverse of their original order.
>
> Oh, forgot to say: FWIW - I think reversing and then sort.SliceStable
> might be a solution - asymptotically reverse should be less complex than
> the sort, or probably there are other variations that don't require
> reimplementing sorting.
> On Tuesday, December 6, 2022 at 7:47:04 PM UTC-8 Andrew Harris wrote:
>
>> Just as an intuitive argument, we could do:
>> sort.Slice(s, func(i, j int) bool { log.Println(i, j); return i > j })
>>
>> The appearances of i and j per step recapitulate the logic of the sorting
>> algo in some weak sense; not slice order
>> On Tuesday, December 6, 2022 at 7:28:39 PM UTC-8 hey...@gmail.com wrote:
>>
>>> > sorts defined by an ordering function purely dependent on the value of
>>> the element
>>>
>>> Hmm, I thought the function was agnostic to what really get compared? If
>>> it offers two index numbers, and the return value says the one with larger
>>> index number should be at the front, shouldn't the sort function simply do
>>> that, since during the sorting, the passed index number should be stable?
>>> On Wednesday, December 7, 2022 at 11:14:37 AM UTC+8 harr...@spu.edu
>>> wrote:
>>>
>>>> Oh, to reverse by index ... I think this doesn't quite fit in the idea
>>>> of sorts defined by an ordering function purely dependent on the value of
>>>> the element.
>>>>
>>>> I think there may have been a feature request
>>>> <https://github.com/golang/go/issues/47988> for a `slices.Reverse`
>>>> function in golang.org/x/exp/slices - I'm not sure what the status or
>>>> reasoning is on this. FWIW it's not the only approach that might make
>>>> sense
>>>> for traversing a slice in reverse order, and it can be naive when working
>>>> with e.g. bytes holding utf8.
>>>>
>>>> I think this works but I haven't really thought about edge cases...
>>>>
>>>> `reverse(&s)`
>>>>
>>>> func reverse[T any](s *[]T) {
>>>> z := len(*s)
>>>> for a := 0; a < len(*s)/2; a++ {
>>>> (*s)[a], (*s)[z-a-1] = (*s)[z-a-1], (*s)[a]
>>>> }
>>>> }
>>>>
>>>> On Tuesday, December 6, 2022 at 6:54:38 PM UTC-8 hey...@gmail.com
>>>> wrote:
>>>>
>>>>> Thanks for the quick reply.
>>>>>
>>>>> But that seems to compare values. I'd like to compare index numbers.
>>>>> The fact that original values follow index number order is a coincidence.
>>>>>
>>>>> > I think it'd be recommended to look at the generics slices package,
>>>>> which also has a sort
>>>>>
>>>>> Do you mean golang.org/x/exp/slices? That also seems to only compare
>>>>> values.
>>>>>
>>>>>
>>>>> On Wednesday, December 7, 2022 at 10:45:33 AM UTC+8 harr...@spu.edu
>>>>> wrote:
>>>>>
>>>>>> Subtly:
>>>>>> return s[i] > s[j]
>>>>>>
>>>>>> Is the right sort func
>>>>>>
>>>>>> I think it'd be recommended to look at the generics slices package,
>>>>>> which also has a sort
>>>>>> On Tuesday, December 6, 2022 at 6:39:29 PM UTC-8 hey...@gmail.com
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I have this very simple sorting code:
>>>>>>>
>>>>>>> s := make([]int, 0, 100)
>>>>>>> for i := 1; i <= 20; i++ {
>>>>>>> s = append(s, i)
>>>>>>> }
>>>>>>> sort.Slice(s, func(i, j int) bool { return i > j })
>>>>>>> log.Print(s)
>>>>>>>
>>>>>>> I expect it to print numbers in reverse order, since items with
>>>>>>> larger index numbers should be at the front. However, at lease in
>>>>>>> go1.19.3,
>>>>>>> it prints
>>>>>>>
>>>>>>> [9 1 8 5 16 3 20 2 10 7 12 13 14 15 6 4 19 18 17 11]
>>>>>>>
>>>>>>> I guess I must have misunderstood how the sort package works, but
>>>>>>> rereading sort's doc multiple time doesn't help answer the question.
>>>>>>>
>>>>>>> Could anyone shed some light?
>>>>>>>
>>>>>>
--
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/57b141f1-a320-4e80-b646-890118552d9bn%40googlegroups.com.
Re: [go-nuts] Generic type alias with type conversion
Thanks for the reply.
Does that mean it's currently not possible to conditionally implement a
method based on type parameters? And the solution should probably be that I
use CanConvert from reflect do that at runtime?
On Monday, November 4, 2024 at 1:47:30 PM UTC+8 Ian Lance Taylor wrote:
> On Sun, Nov 3, 2024 at 12:41 AM hey...@gmail.com wrote:
> >
> > Not sure generic type alias is the solution, but what I'm trying to do
> is I have a type like this
> >
> > type Map[K comparable, V any] struct { m map[K]V }
> >
> > and I want it to implement json.Unmarshaller to decode json objects,
> when K's underlying type is string:
> >
> > type omap[K ~string, V any] = Map[K, V]
> > func (m *omap[K, V]) UnmarshalJSON(data []byte) error {
> > k := "a"
> > v :=1
> > m[K(k)] = v
> > }
> >
> > Go 1.23 with the aliastypeparams flag enabled, currently complains
> "cannot convert k (variable of type string) to type K".
> >
> > I wonder if using alias this way is wrong and if there exists another
> solution?
>
> A type alias is just an alias. When you declare a method on the alias
> map, you are declaring a method on the type Map. That means that the
> ~string in the omap definition is ignored for the method definition;
> all that matters is the comparable constraint in the Map definition.
> You can't in general convert a string to a comparable type.
>
> 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 visit
https://groups.google.com/d/msgid/golang-nuts/3b54013b-8d8d-4eb8-9e3b-77b50de0d3ebn%40googlegroups.com.
[go-nuts] Generic type alias with type conversion
Not sure generic type alias is the solution, but what I'm trying to do is I
have a type like this
type Map[K comparable, V any] struct { m map[K]V }
and I want it to implement json.Unmarshaller to decode json objects, when
K's underlying type is string:
type omap[K ~string, V any] = Map[K, V]
func (m *omap[K, V]) UnmarshalJSON(data []byte) error {
k := "a"
v :=1
m[K(k)] = v
}
Go 1.23 with the aliastypeparams flag enabled, currently complains "cannot
convert k (variable of type string) to type K".
I wonder if using alias this way is wrong and if there exists another
solution?
--
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 visit
https://groups.google.com/d/msgid/golang-nuts/d349ca09-7b2b-43bf-a069-c35db3fa27f1n%40googlegroups.com.
