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 a possible runtime panic converted to a compiler error is an increase in how robust the code is. The weird part, at least, why it might feel weird, is that you might never encounter the issue as a runtime panic, but as a compiler error, it will hit you every time. This will make exploring and experimenting with unfamiliar imports, features, and patterns more complicated, but it is the entire point, to my mind, of having a type-system. P.S. Bug in the snippet given by OP? I expected to see "x != nil" instead of "x == nil", or else change comments around. On Wednesday, March 23, 2022 at 4:15:13 PM UTC-5 axel.wa...@googlemail.com wrote: > 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 > like a lose-lose proposition to me. > > Of course, people can always choose to write/use whatever static checker > they want. I'm not opposed to this existing. I just don't think it should > be in the compiler or in `go vet`. > > On Wed, Mar 23, 2022 at 10:01 PM 'Michael Toy' via golang-nuts < > golan...@googlegroups.com> wrote: > >> 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 >> checked for nil ... It took me a while to get used to languages which do >> this, but now I can't imagine living without it. >> >> Is it crazy to wish for ... >> >> if x == nil { >> // this does not produce an error because x is known not to be nil >> x.interfaceFunc() >> } >> // this DOES produce an error/warning if y is possibly nil >> y.interfaceFunc() >> >> -- >> 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/5a700cd9-9274-4756-80a6-9d322232afebn%40googlegroups.com >> >> <https://groups.google.com/d/msgid/golang-nuts/5a700cd9-9274-4756-80a6-9d322232afebn%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/14f6ade8-fe5b-4876-b692-ed98764eaa55n%40googlegroups.com.
