s/code/cost
On Tuesday, March 18, 2025 at 10:22:48 PM UTC+8 tapi...@gmail.com wrote:
> Inline cost is estimated at compile time, not the real code.
>
> But I sorry to say "*new(T) has a smaller inline cost than T{}". it is a
> little larger in fact.
> The inline cost of
chak wrote:
> On Mon, 2025-03-17 at 21:03 -0700, tapi...@gmail.com wrote:
> > I prefer *new(T) over T{}, because not only the reason here, but also
> > the former has a smaller inline cost.
>
> What do you mean by "inline cost"?
>
> https://godbolt.org/z/h8Krq7W8G
I prefer *new(T) over T{}, because not only the reason here, but also the
former has a smaller inline cost.
On Monday, March 17, 2025 at 4:49:51 PM UTC+8 Jan Mercl wrote:
> On Mon, Mar 17, 2025 at 9:45 AM tapi...@gmail.com
> wrote:
>
> > You can use *new(Version) instead of Ver
You can use *new(Version) instead of Version{} to avoid parsing ambiguity.
On Sunday, March 16, 2025 at 9:30:25 PM UTC+8 Christophe Meessen wrote:
> Hello,
>
> You'll find the minimal example code generating the compilation error
> here: https://go.dev/play/p/Vb-dNr2DpzM
>
> It is easy to get ar
Just read https://go101.org/article/type-embedding.html
The full form of the EqualName field is meter.EqualName,
the full form of the EqualName method is mete.EqualName.EqualName.
The longer one is shadowed by the shorter one.
func main() {
impl := new(impl)
var m = &meter{
EqualName: impl,
}
An alternative std package list: https://docs.go101.org/std/index.html
On Sunday, February 2, 2025 at 2:28:15 PM UTC+8 Axel Wagner wrote:
> Yupp:
> https://pkg.go.dev/std
>
> On Sun, 2 Feb 2025 at 07:21, will@gmail.com
> wrote:
>
>> To be clear, I mean see a listing of all the packages in t
an't think of any other behavior which is possible.
>
> On Thursday, 30 January 2025 at 19:27:51 UTC tapi...@gmail.com wrote:
>
>> On Tuesday, January 28, 2025 at 7:07:15 PM UTC+8 Brian Candler wrote:
>>
>> > The documentation tells that Fscanln() is similar to Fsc
On Tuesday, January 28, 2025 at 7:07:15 PM UTC+8 Brian Candler wrote:
> The documentation tells that Fscanln() is similar to Fscan(), my test
shows that it isn't true for some cases.
"similar" does not mean "the same as".
Fscanln chomps the fields given, then chomps the next character. If th
see https://go101.org/q-and-a/make-dirty-byte-slices.html
On Tuesday, January 14, 2025 at 9:44:40 PM UTC+8 Vasiliy Tolstov wrote:
> Hi! I'm try to search answers but have no luck. In go i can create
> memory arena/ buffer pool etc..
> But does it possible to get memory with like make([]byte, XXX)
On Tuesday, December 31, 2024 at 9:42:50 AM UTC+8 tapi...@gmail.com wrote:
On Monday, December 30, 2024 at 6:12:10 AM UTC+8 Axel Wagner wrote:
Why don't I use the sequence versions more frequently? Because I try not to
create huge in-memory maps and instead prefer to move logic
There is not a phase between in-between, Any evaluation must happen in
either of the two phases.
On Sunday, December 29, 2024 at 3:13:38 PM UTC+8 Kaiming Yang wrote:
> An update from the bug: Seems the behavior is WAI because the execution
> order of dereference and function calls are not defi
On Monday, December 30, 2024 at 6:12:10 AM UTC+8 Axel Wagner wrote:
Why don't I use the sequence versions more frequently? Because I try not to
create huge in-memory maps and instead prefer to move logic that
manipulates large amounts of data into a proper database.
Iterators are more effi
Please note that "maps.Collect" is slow.
https://github.com/golang/go/issues/68261
It is best to write your own custom Collect function.
On Monday, December 30, 2024 at 5:50:47 AM UTC+8 Mike Schinkel wrote:
> > On Dec 29, 2024, at 1:28 AM, Axel Wagner
> wrote:
> >
> > At the end of the day,
If you want to know clearly which toolchain version you are using,
you can try GoTV (https://go101.org/apps-and-libs/gotv.html).
I have used it for two years almost without touching the `go` command
directly.
On Saturday, December 21, 2024 at 6:07:35 AM UTC+8 Jeffery Carr wrote:
> Wow. This syn
On Friday, November 22, 2024 at 5:27:10 PM UTC+8 Lin Lin wrote:
Hi, gophers, here is our dilemma.
We build system managing infrastructure such as Kubernetes. With that comes
the need to write
a lot of maintenance scripts. For now they are all written in Bash, which
is hard to edit and test.
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 }
>
>
Why do you have to use alias here? What is the problem if omap is not an
alias?
On Monday, November 4, 2024 at 6:39:51 PM UTC+8 hey...@gmail.com wrote:
Thanks for the reply.
Does that mean it's currently not possible to conditionally implement a
method based on type parameters? And the solut
On Thursday, October 31, 2024 at 10:24:23 PM UTC+8 Nico Braun wrote:
I think not closing the channel has the side effect, of making it easier
to leak goroutines. If your memory is growing, its likely that there is
still a receiver who didn't realize there is nothing more to receive.
That is one
https://github.com/golang/go/issues/21985
https://github.com/golang/go/issues/28017
Personally, I think this is an interesting idea.
On Thursday, October 24, 2024 at 9:08:33 PM UTC+8 Aniket Pandey wrote:
> Has anyone have implemented the logic in order to check if the channel is
> active if th
On Thursday, October 10, 2024 at 11:51:02 AM UTC+8 Nico Braun wrote:
Hi, recently I became very self aware of potential performance implications
my code might have.
In go there are a few key concepts, like escape analysis and bound checks.
If you check the standard library, you can see it was
s/hard/harm
On Wednesday, October 2, 2024 at 12:50:59 PM UTC+8 tapi...@gmail.com wrote:
> On Monday, September 30, 2024 at 1:51:17 PM UTC+8 Hikmatulloh Hari Mukti
> (Hari) wrote:
>
> > Maybe I should apologize for the origin of this idea:
> https://github.com/go101/go101/wik
orld case for this though.
If someone want to intentionally keep alive slice's underlying array,
she/he can use s[:0] instead.
On Friday 27 September 2024 at 14:16:36 UTC+7 tapi...@gmail.com wrote:
Maybe I should apologize for the origin of this idea:
https://github.com/go101/go101/wiki/How
Maybe I should apologize for the origin of this idea:
https://github.com/go101/go101/wiki/How-to-perfectly-clone-a-slice%3F
When I posted that wiki article, I was not aware of this (maybe tiny)
drawback.
My current opinion is that it is best to let the Go runtime specialize
zero-capacity slic
see: https://github.com/golang/go/issues/65878
package main
var a, b [0]int
var p, q = &a, &b
func main() {
if (p == q) {
p, q = &a, &b
println(p == q) // false
}
}
On Thursday, June 20, 2024 at 12:59:43 AM UTC+8 Oliver Eikemeier wrote:
> I'm observing some strange behavior and could use some
e you did not get your will at the time, you are
now bringing it up to troll unrelated conversations. With no actually
coherent position.
And so your "one-sentence emoticon" message is neither charming, clever,
witty nor funny. It's simply disrespectful.
👍
On Thu, Feb 29, 202
On Thursday, February 29, 2024 at 3:14:40 PM UTC+8 Axel Wagner wrote:
The loop var change *does* break compatibility. And it did so knowingly and
- as clearly explained - was an exception.
Stop arguing in bad faith.
An exception.
:D
On Thu, Feb 29, 2024 at 7:03 AM tapi...@gmail.com
On Wednesday, February 28, 2024 at 3:19:37 PM UTC+8 Axel Wagner wrote:
That would break backwards compatibility, though. And it would be a
re-definition (i.e. existing code would compile, but behave differently at
runtime) and is hence not allowed even under the Go 2 transition rules.
With G
On Tuesday, February 27, 2024 at 3:42:25 PM UTC+8 Jan Mercl wrote:
On Tue, Feb 27, 2024 at 6:20 AM tapi...@gmail.com
wrote:
> From common sense, this is an obvious bug. But the spec is indeed not
clear enough.
> It doesn't state whether or not comparisons of pointers to two dis
use
type Test[T, V interface{A; I}] struct{}
instead now.
There are still several restrictions in custom generics:
https://go101.org/generics/888-the-status-quo-of-go-custom-generics.html
On Monday, February 26, 2024 at 10:44:46 PM UTC+8 Albert Widiatmoko wrote:
> Hi Go community,
>
> I
>> it would be valid for `==` on pointers to zero-sized types to always
evaluate to `true`,
This would be more straightforward behavior.
On Feb 26, 2024, at 9:24 AM, tapi...@gmail.com wrote:
package main
var a, b [0]int
var p, q = &a, &b
func main() {
if (p == q) {
p, q = &am
package main
var a, b [0]int
var p, q = &a, &b
func main() {
if (p == q) {
p, q = &a, &b
println(p == q) // false
}
}
On Thursday, February 22, 2024 at 6:55:49 PM UTC+8 Brien Colwell wrote:
> I'm confused by this output. It appears that the interface of two
> different pointers to an empty str
The behavior of Go 1.9 or 1.10 is even more weird.
They make the following code print false. ;D
package main
type T struct {}
func main() {
var a, b = &T{}, &T{}
println(a == b || a != b)
}
On Sunday, February 25, 2024 at 4:30:22 PM UTC+8 tapi...@gmail.com wrote:
> Absol
Absolutely a bug.
On Thursday, February 22, 2024 at 6:55:49 PM UTC+8 Brien Colwell wrote:
> I'm confused by this output. It appears that the interface of two
> different pointers to an empty struct are equal. In all other cases,
> interface equality seems to be the pointer equality. What's goin
See https://github.com/golang/go/issues/2205
The tip compiler is able to detect some simple string->[]byte cases in
which duplication is not needed.
On Monday, November 27, 2023 at 8:12:54 PM UTC+8 fliter wrote:
> It seems that go 1.22 has optimized the implementation of string to byte
> slicin
The uint8 in cachedFn[uint8, V] is the type parameter name, it can be
arbitrary valid identifier.
It shadows the predeclared uint8 identifier.
On Friday, November 10, 2023 at 12:25:05 PM UTC+8 ahuigo wrote:
> Btw, please ignore the type logic in my code, I wrote this piece of code
> just to ill
My another surprise is that the below partial instantiation doesn't work.
s = slices.Insert[[]Suiter](s, len(s), Clubs{}) // not work
s = slices.Insert[[]Suiter, Suiter](s, len(s), Clubs{}) // works
On Monday, October 23, 2023 at 11:01:47 AM UTC+8 tapi...@gmail.com wrote:
> On Monday,
gt; figure it out.
>
> -Mike
> On Sunday, October 22, 2023 at 11:01:47 PM UTC-4 tapi...@gmail.com wrote:
>
>> On Monday, October 23, 2023 at 10:38:59 AM UTC+8 tapi...@gmail.com wrote:
>>
>> Sorry, I didn't look your full code.
>> I think the full code sho
On Monday, October 23, 2023 at 10:38:59 AM UTC+8 tapi...@gmail.com wrote:
Sorry, I didn't look your full code.
I think the full code should work with Go toolchain 1.21.n.
Aha, it actually doesn't. I'm surprised.
On Sunday, October 22, 2023 at 4:40:55 PM UTC+8 Mike Schinkel
me other negative?
>
> -Mike
>
> On Saturday, October 21, 2023 at 11:57:52 PM UTC-4 tapi...@gmail.com
> wrote:
>
>
> It is hard to call such type inference better. That is too aggressive.
>
>
--
You received this message because you are subscribed to the Google Groups
&quo
On Sunday, October 22, 2023 at 4:09:51 AM UTC+8 Mike Schinkel wrote:
@Axel Wagner —
Thank you for adding clarity to this.
Yes, it would be nice if we could get this to be handled with better type
inference.
It is hard to call such type inference better. That is too aggressive.
But unl
On Friday, July 28, 2023 at 6:44:21 AM UTC+8 wagner riffel wrote:
On 27/07/2023 03:48, Kyle Harrity wrote:
> Maybe this is a known issue and or expected behavior so I thought I'd
> ask here before raising an issue on github.
>
I think I know what's going on, the compiler inlined getStrBytes
Type inference is not the main purpose (or even the purpose) of short
declarations.
I do agree that the negative impact of short declarations is larger than
its positive impact,
for reasons different from the one you described. Some reasons:
* short declarations causes confusions (esp, for new g
Not to mention that the change for "for;;" is so counter-intuitive and
violates the try-to-be-explicit principle in Go.
On Wednesday, April 12, 2023 at 9:08:24 AM UTC+8 tapi...@gmail.com wrote:
> The plan for “for;;” is much more risky than “for-each”, because “for;;”
> has mor
The plan for “for;;” is much more risky than “for-each”, because “for;;”
has more variation uses in reality.
I have no doubt that many non-bug compatibility-broken or
performance-degradation cases will be found in the GOEXPERIMENT phase.
On Saturday, March 25, 2023 at 2:44:59 PM UTC+8 Amnon wrot
I ever also found this problem: global ballast doesn't work.
So I always use local ballast instead now.
On Sunday, November 6, 2022 at 8:37:55 PM UTC+8 hit.zh...@gmail.com wrote:
> Before, I think the memory is allocated by mmap anon, which Linux OS
> guarantees reading will return zero value an
You may also try Golds: https://github.com/go101/golds.
Still not perfect in handling custom generic things,
but it is generally usable.
On Friday, November 4, 2022 at 1:26:26 AM UTC+8 Hotei wrote:
> Thanks for the very helpful replies. < go doc -all pkg > should meets my
> needs for printed doc
gt; say that your reply is invalid. I'm just curious how you view your reply as
>> being more clear than mine. :-)
>>
>>
>>> On Fri, Oct 28, 2022 at 8:57 PM tapi...@gmail.com
>>> wrote:
>>>
>>>> The max array length is math.MaxInt. &qu
The max array length is math.MaxInt. "[math.MaxInt]struct{}" is valid,
though the practical size of non-zero-size array is hard limited in some
way.
On Friday, October 28, 2022 at 9:43:16 AM UTC+8 eric...@arm.com wrote:
> The spec says that " The length is part of the array's type; it must
> ev
On Monday, October 10, 2022 at 3:11:06 PM UTC+8 Brian Candler wrote:
> > By the go module cache system design, if you trust the server set in
> your GOSUMDB env var,
> > which is defaulted to sum.golang.org, then it is not a matter whatever
> proxy server your are using.
>
> From the point of
On Sunday, October 9, 2022 at 11:50:49 PM UTC+8 ljh wrote:
> Hi, community,
>
> I Just saw this site: yunzhanghu.com , is listed as Special Sponsor on
> goproxy.io homepage.
>
> I'm just curious, is goproxy.io endorsed by The Go Team and is goproxy.io
> trustworthy?
>
By the go module cache
I don't know if it satisfies your need, but you can try Golds:
https://go101.org/apps-and-libs/golds.html
On Sunday, September 11, 2022 at 5:28:35 AM UTC+8 brainman wrote:
> Hello Everyone,
>
> I would like to run go documentation server that have access to my private
> code.
>
> Is it possible
On Saturday, August 20, 2022 at 10:58:10 PM UTC+8 tapi...@gmail.com wrote:
> On Friday, August 19, 2022 at 12:14:55 AM UTC+8 k...@google.com wrote:
>
>> On Wednesday, August 17, 2022 at 8:18:35 PM UTC-7 tapi...@gmail.com
>> wrote:
>>
>>> I'm a bit wonderin
s 0%: 0.098+2.6+0.011 ms clock, 0.39+0/2.5/7.5+0.044 ms cpu,
0->0->0 MB, 118 MB goal, 128 MB stacks, 8 MB globals, 4 P (forced)
2022/08/20 22:52:02 16777216 3
On Saturday, August 20, 2022 at 10:58:10 PM UTC+8 tapi...@gmail.com wrote:
> On Friday, August 19, 2022 at 12:14:55 AM UTC+8 k
On Friday, August 19, 2022 at 12:14:55 AM UTC+8 k...@google.com wrote:
> On Wednesday, August 17, 2022 at 8:18:35 PM UTC-7 tapi...@gmail.com wrote:
>
>> I'm a bit wondering about how the following case will be affected by the
>> change:
>> 1. Initially, there is on
I'm a bit wondering about how the following case will be affected by the
change:
1. Initially, there is one goroutine, which stack size is large at the time
of a GC process.
2. After the GC process, a large quantity of goroutines start. They all
need small stacks.
But now the runtime will all
I tend to think it should print 1, as well this one:
https://go.dev/play/p/bax7CoaSV1d
On Monday, August 15, 2022 at 3:34:35 PM UTC+8 tapi...@gmail.com wrote:
> It would be good if the Memory Model article shows some atomic examples.
>
> On Monday, August 15, 2022 at 3:06:58 PM
By the latest version of Go Memory Model article: https://go.dev/ref/mem,
will the following program always print 1?
https://go.dev/play/p/RICYGip5y8M
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop recei
commend but not force them to use a recent version.
And this is not a 1.15/1.16 specific problem.
>
> On Tuesday, 10 May 2022 at 01:24:12 UTC+1 tapi...@gmail.com wrote:
>
>> On Tuesday, May 10, 2022 at 1:46:35 AM UTC+8 Ian Lance Taylor wrote:
>>
>>> On Mon, May 9, 2
On Tuesday, May 10, 2022 at 1:46:35 AM UTC+8 Ian Lance Taylor wrote:
> On Mon, May 9, 2022 at 10:18 AM tapi...@gmail.com
> wrote:
> >
> > I have a project using go1.16 embedding feature.
> > The project supports Go toolchain 1.15, by using "//go:build !go1.16&q
I have a project using go1.16 embedding feature.
The project supports Go toolchain 1.15, by using "//go:build !go1.16"
directive.
Now I have upgraded the toolchain to v1.18.1,
And I want to debug the non-embedding flow of the project.
Changing the go version in go.mod doesn't help.
Do I have to
On Wednesday, May 4, 2022 at 7:01:48 AM UTC+8 se...@liao.dev wrote:
> right now it only works if the structs are actually identical:
> https://go.dev/play/p/tMG3SYG5fLN
>
> - sean
>
>
Though accessing fields is still not allowed.
>
> On Tue, May 3, 2022 at 8:06 PM sbezverk wrote:
>
>> Hello,
Ah, I forgot that point.
Thanks for the explanation!
On Saturday, April 2, 2022 at 10:00:27 PM UTC+8 axel.wa...@googlemail.com
wrote:
> Ptr[int] is a defined type, `*int` is not. So the two types are not the
> same and this is working as intended.
>
> On Sat, Apr 2, 2022 at
package main
type Ptr[E any] *E
type MyConstraint interface {
Ptr[int]
}
type YourConstraint interface {
*int
}
func foo[T MyConstraint](x T) {
}
func bar[T YourConstraint](x T) {
}
func main() {
var x = new(int)
foo(x) // *int does not implement MyConstraint
bar(x)
}
--
Aha, sorry, the file order really matters here.
But for this specified case, it should not.
That's not right. I remembered in an issue thread, it is mentioned that the
order should be
1. D is not ready (because it depends on A)
2. A is ready, so it is initialized: it gets value 3.
4. B is init
Then I think interface{int; m()} and interface{bool;; m()} should be
identical.
Because their type sets are both empty..
On Thursday, March 24, 2022 at 7:38:10 PM UTC+8 Jan Mercl wrote:
> On Thu, Mar 24, 2022 at 11:58 AM tapi...@gmail.com
> wrote:
>
> https://go.dev/ref/spec#T
BTW, the rewritten version outputs
Init A
Init B
Init C
1 4 3
On my machine (go1.18 linux/amd64).
On Thursday, March 24, 2022 at 7:30:37 PM UTC+8 tapi...@gmail.com wrote:
> > 2. A < D < B < C - happens when f2.go is passed first to the compiler.
> In this case, the *expe
> 2. A < D < B < C - happens when f2.go is passed first to the compiler. In
this case, the *expected output *would be "1 2 1". However, the *actual
output* is "1 2 3".
This is not true by my understanding of the spec.
https://go.dev/ref/spec#Package_initialization
If f2.go is passed first, then
.
--
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
Is it hard to add two predeclared constraints, convertibleFrom and
convertibleTo, just like comparable?
On Tuesday, March 22, 2022 at 11:07:41 PM UTC+8 Ian Lance Taylor wrote:
> On Tue, Mar 22, 2022 at 6:01 AM tapi...@gmail.com
> wrote:
> >
> >
> >
> > On Monday
] = vs[i]
}
return r
}
>
>
> On Sunday, March 20, 2022 at 11:36:27 PM UTC+7 tapi...@gmail.com wrote:
>
>>
>>
>> package main
>>
>> type A interface {
>> Ma()
>> }
>>
>> type B interface {
>> Mb()
> *type parameters *itself is not a type, but a list of type parameters.
true. The spec means a single type parameter is a named type.
On Monday, March 21, 2022 at 12:12:26 AM UTC+8 xiej...@gmail.com wrote:
> Hi there.
>
> I am reading go spec. When hit the "Types" section,
>
> https://go
package main
type A interface {
Ma()
}
type B interface {
Mb()
}
type Ta struct { A }
type Tb struct { B }
func ConvertSliceToA[From A](vs []From) []A {
var r = make([]A, len(vs))
for i := range vs {
r[i] = vs[i]
}
return r
}
f
The tip spec states that the core type of a constraint is born from the
type set of the constraint. https://tip.golang.org/ref/spec#Core_types
So the C constraint in the following program should have no core type,
because its type set is blank. But the foo function compiles okay,
which indicates
Thanks for the reply, gri.
The latest generics design and implementation are much more beautiful than
I expected, though I still think there are many restrictions.
BTW, it looks the following line in spec becomes depreciated now, as now
any type could be embedded in interfaces.
In a slightly m
On Thursday, January 6, 2022 at 11:19:40 PM UTC+8 tapi...@gmail.com wrote:
> On Thursday, January 6, 2022 at 9:40:52 PM UTC+8 tapi...@gmail.com wrote:
>
>> On Thursday, January 6, 2022 at 8:35:06 PM UTC+8 Brian Candler wrote:
>>
>>> No, the mistake is in your re
On Thursday, January 6, 2022 at 9:40:52 PM UTC+8 tapi...@gmail.com wrote:
> On Thursday, January 6, 2022 at 8:35:06 PM UTC+8 Brian Candler wrote:
>
>> No, the mistake is in your reading of the spec. You are complaining
>> about this line:
>>
>> interface{ i
sorry again. It should be "the type set and specific types of interface{
int; any } are both {int}."
On Thursday, January 6, 2022 at 9:45:35 PM UTC+8 tapi...@gmail.com wrote:
> On Thursday, January 6, 2022 at 9:44:05 PM UTC+8 tapi...@gmail.com wrote:
>
>> On Thursday, Janu
On Thursday, January 6, 2022 at 9:44:05 PM UTC+8 tapi...@gmail.com wrote:
> On Thursday, January 6, 2022 at 9:40:49 PM UTC+8 Brian Candler wrote:
>
>> So to be more specific, I think you're asking why this code works:
>> https://gotipplay.golang.org/p/kuYzzx4EJY1
>&g
On Thursday, January 6, 2022 at 9:40:49 PM UTC+8 Brian Candler wrote:
> So to be more specific, I think you're asking why this code works:
> https://gotipplay.golang.org/p/kuYzzx4EJY1
>
> Sorry, I made a mistake in interpreting the spec. It also says:
>
> "The type set of the empty interface is
the set of one type (int) with the
> empty set, and therefore the result is the empty set. Exactly as the
> comment says.
>
> On Thursday, 6 January 2022 at 11:47:52 UTC tapi...@gmail.com wrote:
>
>> On Thursday, January 6, 2022 at 6:15:06 PM UTC+8 Brian Candler wrote:
>>
3. "interface { int; any }" is an *intersection* of *specific types*
>
> You are taking the intersection of the set of one type (int) with the
> empty set, and therefore the result is the empty set. Exactly as the
> comment says.
>
> On Thursday, 6 January 2022 at 11
On Thursday, January 6, 2022 at 6:15:06 PM UTC+8 Brian Candler wrote:
> 1. interface { a;b } is intersection. The "Intersection" between two sets
> means things which exist in both sets simultaneously.
> 2. interface { a|b } is union. "Union" means a set of things which which
> exist in set A
Should it be
interface{ int | any } // no specific types (intersection is empty)
instead
On Wednesday, January 5, 2022 at 11:20:16 PM UTC+8 tapi...@gmail.com wrote:
> https://tip.golang.org/ref/spec#Structure_of_interfaces
>
>interface{ int; any } // no specific types (inters
https://tip.golang.org/ref/spec#Structure_of_interfaces
interface{ int; any } // no specific types (intersection is empty)
Why the constraint has no specific types. Doesn't it specify int?
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To
Isn't the code should be:
*func CopyFile() {*
* ...*
* if err != nil {*
* return*
* }*
* defer func() { err = src.Close() }()*
* ...*
*}*
On Thursday, November 25, 2021 at 12:18:20 PM UTC+8 Ian Lance Taylor wrote:
> On Wed, Nov 24, 2021 at 6:14 PM Fannie Zhang wrote:
> >
> > The
There is an issue for this: https://github.com/golang/go/issues/17378
On Sunday, November 14, 2021 at 1:46:29 AM UTC+8 arthurwil...@gmail.com
wrote:
> On a 64bit Mac, this code:
>
> package main
>
> var X [^uint(0)>>14]byte
> func main() {
> }
>
> produces a compile time error:
> main.X: symbol
It is 1 << 50 is the limit on heap. The following code doesn't compile:
package main
func main() {
var X [1 << 50]byte // type [1125899906842624]byte larger than address
space
_ = X
}
But with 1 << 50 - 1, it compiles:
package main
func main() {
var X [1 << 50 - 1]byte // runtime:
fill an issue here: https://github.com/golang/go/issues/49744
On Tuesday, November 23, 2021 at 12:15:52 AM UTC+8 tapi...@gmail.com wrote:
> Slower about 20%. As least, on my machine, it looks so.
> As my machine is slow, I haven't use -count=10 and benchstat to make a
> report
Slower about 20%. As least, on my machine, it looks so.
As my machine is slow, I haven't use -count=10 and benchstat to make a
report.
--
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
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...@gmai
>
> 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...@
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:
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, 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
>>>
>>>
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
pe
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
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 {
struc
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` w
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)
&g
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 th
1 - 100 of 272 matches
Mail list logo
