On Tue, May 3, 2022 at 8:32 AM Will Faught wrote:
> Just as pointer comparisons are shallow, so too are comparisons for types
> that contain pointers.
Pointer comparisons are not shallow. Comparing two pointers compares
the entire values. a == b and *a == *b compare different values but in
both
>
> There are cases involving closures, generated trampolines, late
> binding and other details that mean that doing this will either
> eliminate many optimization possibilities or restrict the compiler too
> much or cause surprising results. We disabled function comparison for
> just these reasons
* Functions: Compare the corresponding memory addresses. The time
complexity is constant.
There are cases involving closures, generated trampolines, late
binding and other details that mean that doing this will either
eliminate many optimization possibilities or restrict the compiler too
much or c
You seem to have misunderstood the point. It's an idea for changing the
language. You're just demonstrating the current behavior, which is what
would be changed. The argument is to make `make([]int, 2) == make([]int,
2)` legal, and evaluate to false.
On Mon, May 2, 2022 at 8:22 PM Kurtis Rader wr
On Mon, May 2, 2022 at 7:44 PM will@gmail.com
wrote:
> ```
> type Slice1000[T any] struct {
> xs *[1000]T
> len, cap int
> }
>
> func (s Slice1000[T]) Get(i int) T {
> // ...
> return s.xs[i]
> }
>
> func (s Slice1000[T]) Set(i int, x T) {
> // ...
> s.xs[i] = x
> }
>
All types should have unrestricted comparisons (`==`, `!=`), but a few
pre-declared types don't. Adding them would bridge a semantic gap between
pre-declared and user-declared types, enabling all types to be used as map
keys, and otherwise make reasoning about them more consistent and intuitive.
actually just changing Example's to Test's with a string comparison seems
to have the least friction.
On Monday, 2 May 2022 at 21:57:29 UTC+1 simon place wrote:
> i see, thanks
>
> the implementation of 'go test' (which the playground runs
> auto-magically.) replaces os.Stdout with a new refere
On Mon, May 2, 2022 at 2:57 PM 'simon place' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> i see, thanks
>
> the implementation of 'go test' (which the playground runs
> auto-magically.) replaces os.Stdout with a new reference behind the scenes
> before running the func, but after makin
i see, thanks
the implementation of 'go test' (which the playground runs auto-magically.)
replaces os.Stdout with a new reference behind the scenes before running
the func, but after making global vars, so the code as written isn't
strictly 'go' anymore.
https://go.dev/play/p/3FBjOmzYIiz?v=gop
On Mon, May 2, 2022 at 9:00 AM psi@gmail.com wrote:
> #1 the two functions need to behave identically according to the syntax of
> the language.
>
> #2 this is how working code operates, so testing needs to be able to
> handle it.
>
> at a guess; 'testing' would appear to have some non-compli
Code needs to be written to be testable.
Peter is correct, you've taken a reference to an uninstrumented os.Stdout.
What you've written isn't identical wrt to the evaluation of stdout, so
can't be expected to perform identically.
--
You received this message because you are subscribed to the Goog
Please follow the Go Community Code of Conduct while posting here.
https://go.dev/conduct
On Monday, May 2, 2022 at 11:00:14 AM UTC-4 psi@gmail.com wrote:
> #1 the two functions need to behave identically according to the syntax of
> the language.
>
> #2 this is how working code operates,
#1 the two functions need to behave identically according to the syntax of
the language.
#2 this is how working code operates, so testing needs to be able to handle
it.
at a guess; 'testing' would appear to have some non-compliant reflection
going on, in this edge-case.
but anyway; your reply
https://www.tillett.info/2013/05/13/how-to-create-a-windows-program-that-works-as-both-as-a-gui-and-console-application/
> On May 2, 2022, at 8:27 AM, 'Anderson Queiroz' via golang-nuts
> wrote:
>
> You could log to a file. If you're willing to take in a -log flag, you could
> take a path as
You could log to a file. If you're willing to take in a -log flag, you
could take a path as well and log to this file. That way you don't need 2
binaries, however you'd need to tail the file, which seems to me better
than 2 binaries.
Best,
Anderson
On Friday, April 29, 2022 at 2:47:06 PM UTC+
15 matches
Mail list logo
