I was really annoyed that, apparently, I accidentally deleted the message
you're replying to, immediately after writing it.
I agree with you about being possibly surprised by values of outside of an
expected range. The benefit of the above is merely that accessing it is
guaranteed to be
On Mon, Mar 28, 2022 at 12:39 AM Sam Hughes wrote:
> @Axel, I really did mean what I said.
>
So did I.
FTR, if OP would have asked for changes to the type-system to be able to
represent non-nilable types, my response would have been different. I
didn't read their original message as asking for
@Michael%20Toy, I disagree! You're entirely correct to like what TypeScript
does! It's a really cool example of a "modern language" strutting its
stuff -- it's called "Narrowing":
https://microsoft.github.io/TypeScript-New-Handbook/chapters/narrowing/ As
a transpiler targeting Javascript, I
Stephan Lukits
> On 25 Mar 2022, at 20:41, 'Michael Toy' via golang-nuts
> wrote:
>
> The discussion is quite informative
https://m.youtube.com/watch?v=ynoY2xz-F8s
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this
The discussion is quite informative for me to read, thanks for responding.
Go uses nil in a way which I don't quite yet grok, and so I had no idea if
it was even a reasonable thing to wish for. Today I am writing in
Typescript, and the way null is integrated into the type system now (after
a
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
>
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
Personally, I think this leads to very unreadable code, for no real benefit.
If a nil-pointer dereference happens unexpectedly, that's always a bug. A
panic is the correct signal to tell me about that bug, so I can go ahead
and fix it. So, making my code less readable to get less robust code seems
I barely understand Go, so this is likely a stupid idea. Since Go uses nil
for a lot of things, lots of things can be nil.
I am not a huge fan of the null safe accessor.
( https://github.com/golang/go/issues/42847 )
I am a huge fan of the compiler telling me the places where I have not
12 matches
Mail list logo
