I didn't know that you can compose a struct with an interface. Nice.
Typed nils in Go 2
41–50 of 119 posts
Re: Typed nils in Go 2
#42Re: Typed nils in Go 2
#43Re: Typed nils in Go 2
#44Earlier quoted context omitted.
this is called a bottom type in a type system. In JVM languages null and the throw expression return the bottom type. The only other option is to not have nil values.
The problem is "null" being a value in all (non primitive) types, not only the bottom type. You specify "String", but you can have "null" too. When everything is optional, how do you specify that function foo really takes a String, not null? ( https://stackoverflow.com/questions/4963300/which-notnull-ja... )
> The problem is "null" being a value in all (non primitive) types, not only the bottom type.
Null is not a value of bottom type. Bottom type has no values.
Re: Typed nils in Go 2
#45Yet another item to add to my list-of-reasons-of-why-not-to-use-Go. Thanks
I wish people would quit the evangelical crap like that because you can find random bad design patterns and pitfalls in any language. At the end of the day general purpose languages have to fit a large criteria of needs for a wide criteria of developers while evolving and maturing along the process. So there will always be instances where a decision seems right at the time but later turns out to be bad. And even if you take Apple's approach of breaking your language with each iteration (as they do with Swift) you still end up with lots of wasted developer time porting your code with each new release.
Honestly if you aren't a skilled enough programmer to navigate the nuances of any particular language then you really are no better than kids playing in drag-and-drop environments like Scratch.
Re: Typed nils in Go 2
#46Earlier quoted context omitted.
If you don't use languages because they have some edge cases and minor flaws how do you do any programming at all?
Does that sound like an edge case?
Checking the value of a property [edit: return of method] after you've nil'ed the parent object is enough raise an exception in most languages. So yes I'd say that's an edge case. Where Go gets it wrong here is because nil isn't really `nil` you get a silent `false` rather than an obvious crash + stack trace. But regardless of the bad design of Go around the usage of "nil", the code would have failed in pretty much any other language anyway.
Re: Typed nils in Go 2
#47Yet another item to add to my list-of-reasons-of-why-not-to-use-Go. Thanks
If you don't use languages because they have some edge cases and minor flaws how do you do any programming at all?
Having the worst error-handling approach is not an edge case. Plus, the lack of generics is a huge design mistake IMO.
Re: Typed nils in Go 2
#48Earlier quoted context omitted.
The problem is "null" being a value in all (non primitive) types, not only the bottom type. You specify "String", but you can have "null" too. When everything is optional, how do you specify that function foo really takes a String, not null? ( https://stackoverflow.com/questions/4963300/which-notnull-ja... )
> The problem is "null" being a value in all (non primitive) types, not only the bottom type. Null is not a value of bottom type. Bottom type has no values.
Thanks, you are right, the bottom type has no value. I meant the "Null" type, which contains a single value, "null".
Re: Typed nils in Go 2
#49Good example of code smell.
Re: Typed nils in Go 2
#50Earlier quoted context omitted.
Can someone point me to some examples where checking that the type of an interface is nil? I have thought a bit about it but I couldn't come up with good situations.
"the type of an interface is nil" is that even possible?
Yes. The interface holds the concrete type of the value, if there is no concrete type it will be nil, so if you assign a nil to an interface-typed variable directly, you'll have a (nil, nil). If you first assign the nil to a pointer type T then assign/convert that to an interface type, you'll get (* T, nil). Here's a trivial demo:
var a interface{} = nil // (nil, nil)
var b *int = nil
var c interface{} = b // (*int, nil)
fmt.Println(a == c)
And that's vicious because something as seemingly innocuous as "extract variable" on an immutable literal can break your code.