It is good practice for a function to validate the values it receives from
outside, whether they are function arguments or return values from other
functions. It is not just a nil check, but a proper validation. I don't
think that automated nil check can replace proper validation.
Sometimes
On Thu, Mar 24, 2022 at 3:23 AM Brian Candler wrote:
>
> The OP hasn't said specifically which language or feature they're comparing
> with, but I wonder if they're asking for a pointer type which is never
> allowed to be nil, enforced at compile time. If so, a normal
>
On Thu, Mar 24, 2022 at 10:54 AM Tamás Gulácsi wrote:
>
> I'd like to thank The Google Authors for
> https://pkg.go.dev/testing/fstest#MapFS - it just needed a very little
> tweaking to serve as a zip-backed fs.FS:
> https://pkg.go.dev/github.com/tgulacsi/go/zipfs.
>
> The filenames, (missing)
Hi,
I'd like to thank The Google Authors for
https://pkg.go.dev/testing/fstest#MapFS - it just needed a very little
tweaking to serve as a zip-backed fs.FS:
https://pkg.go.dev/github.com/tgulacsi/go/zipfs.
The filenames, (missing) directory names in then zip.Reader.File slice gave
me quite
On Thursday, 24 March 2022 at 12:35:38 UTC tapi...@gmail.com wrote:
> 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
The type set is defined as "all types which implement the interface".
Any type implementing interface{int; m()} has to both
1. have the method m()
2. be the type int
That's not possible. Therefore, the type set of that interface is empty.
The problem is, that the type set is potentially hard to
On Thu, Mar 24, 2022 at 1:56 PM 'Axel Wagner' via golang-nuts
wrote:
> I believe you are correct in that the spec needs work here. The two should
> probably not be considered identical, but they are according to the spec
> right now.
> I'm not sure this poses an immediate problem, as I don't
I believe you are correct in that the spec needs work here. The two should
probably not be considered identical, but they are according to the spec
right now.
I'm not sure this poses an immediate problem, as I don't think such
interfaces can ever appear in a position where type identity matters.
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
Thank you all for the quick replies and helpful comments. I opened an issue
in the go's issue tracker (https://github.com/golang/go/issues/51913).
On Thursday, 24 March 2022 at 13:23:14 UTC+1 Brian Candler wrote:
> Ugh, quoting got broken there.
>
> $ go run rewritten_f1.go f2.go
> Init A
>
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#Type_identity
>
>
Ugh, quoting got broken there.
$ go run rewritten_f1.go f2.go
Init A
Init B
Init C
1 4 3
$ go run f2.go rewritten_f1.go
Init A
Init B
Init C
1 2 1
Hopefully that will show properly.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To
On Thursday, 24 March 2022 at 12:15:16 UTC tapi...@gmail.com wrote:
> BTW, the rewritten version outputs
>
> Init A
> Init B
> Init C
> 1 4 3
>
> On my machine (go1.18 linux/amd64).
>
It depends on the order, and the OP was positing what happens when f2.go is
presented first to the
On Thursday, 24 March 2022 at 11:30:37 UTC tapi...@gmail.com wrote:
> > 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.
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 *expected output *would
On Thu, Mar 24, 2022 at 11:58 AM tapi...@gmail.com wrote:
https://go.dev/ref/spec#Type_identity
Two interface types are identical if they define the same type set.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from
>
> A named type is always different from any other type. Otherwise, two types
> are identical if their underlying type literals are structurally equivalent
Neither type is named, so they are identical, if their underlying type
literals are structurally identical, namely:
Two interface types
> 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,
.
--
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
The OP hasn't said specifically which language or feature they're comparing
with, but I wonder if they're asking for a pointer type which is never
allowed to be nil, enforced at compile time. If so, a normal
pointer-which-may-be-nil would have to be represented as a Maybe[*T] or
union { *T |
One thing to be clear: It is very different if we are talking about "emit a
warning if a value is known to be nil" and "emit a warning unless a warning
is known not to be nil". The former seems fine to me - it is IMO fine for
this code to cause a vet-failure:
var x *int
y := *x
What I'm opposing
Totally get where @Michael%20Troy is coming from. TypeScript is aware of
logical elements as part of ancestry for the current expression, and
provides some helpful warnings in cases where the expression can still be
visited with incompatible predicates.
@axel, it my feel counter-intuitive, but
Having just upgraded to 1.18, I find that quite a few encrypted
connections, for instance https to a Neptune instance on AWS, now fail with:
x509: “*.x.neptune.amazonaws.com” certificate is not standards
compliant
It seems to be related to this comment:
23 matches
Mail list logo
