3 ms·

> hmm. I don't have the problem you're describing, because I generally declare the return struct at the start of the function and then return that. The problem

> hmm. I don't have the problem you're describing, because I generally declare the return struct at the start of the function and then return that. The problem with this is that, in a larger function, I have to read all the way up to confirm if result is an empty value or something else. I think returning myStruct{} is much better, and having a way to easily return a default myStruct would be nice. Calling that "nil" seems to be a bad idea to me, as others are pointing out. > I must admit I don't understand how the proposal works fully. Would `x==nil` return true for an int with value 0? Both answers to this seem wrong to me. I think it would return false in that case. There is already precedent for this in Go, in fact, with arrays/slices. Even though slices themselves are value types (they wrap a pointer) they can be nil, but []someStruct{} == nil is false.

marcus_holmes 5y ago
Yeah but that's because the zero value for slices is an empty slice, not a nil slice. This is what we should have more of. If in the proposal (x==nil) == false then we get the ridiculous position where: var x int x=nil if x==nil { //this never happens despite having just set x=nil } which seems ridiculous. Though the other case, of returning true, also seems ridiculous, because nil and 0 are not the same thing at all.
- Joker_vD 5y ago
  This simply would not compile because of "(mismatched types int and nil)". Solved already. That's why I actually would prefer the "_" syntax: var x int x = _ _ = 42 if x == _ { // this happens even though you've assigned 42 to _, yes }
- simiones 5y ago
  The difference between an empty slice and a nil slice is one of the most inexplicable (to me) warts of the language, especially since it doesn't apply to anything else (maps can't be nil, nil and empty interfaces actually have different properties). Anyway, I do agree that using `nil` as a base case for all types would introduce more confusion. What I think could be useful would be a `default` keyword for this: var x int x = default if x == default { this is true } This would obey rules similar to `iota` in terms of its integration into the language.
  - marcus_holmes 5y ago
    Yeah that would work better than using nil. And it would make it clear that it was being initialised to whatever the default value for that type is. Though, of course, most coders would leave out the second step here since the compiler initialises all variables with their type's default value ;)
    - simiones 5y ago
      Sure :), the really nice example would be return default, default, default, err

marcus_holmes 5y ago

Yeah but that's because the zero value for slices is an empty slice, not a nil slice. This is what we should have more of. If in the proposal (x==nil) == false then we get the ridiculous position where: var x int x=nil if x==nil { //this never happens despite having just set x=nil } which seems ridiculous. Though the other case, of returning true, also seems ridiculous, because nil and 0 are not the same thing at all.

Joker_vD 5y ago
This simply would not compile because of "(mismatched types int and nil)". Solved already. That's why I actually would prefer the "_" syntax: var x int x = _ _ = 42 if x == _ { // this happens even though you've assigned 42 to _, yes }
simiones 5y ago
The difference between an empty slice and a nil slice is one of the most inexplicable (to me) warts of the language, especially since it doesn't apply to anything else (maps can't be nil, nil and empty interfaces actually have different properties). Anyway, I do agree that using `nil` as a base case for all types would introduce more confusion. What I think could be useful would be a `default` keyword for this: var x int x = default if x == default { this is true } This would obey rules similar to `iota` in terms of its integration into the language.
- marcus_holmes 5y ago
  Yeah that would work better than using nil. And it would make it clear that it was being initialised to whatever the default value for that type is. Though, of course, most coders would leave out the second step here since the compiler initialises all variables with their type's default value ;)
  - simiones 5y ago
    Sure :), the really nice example would be return default, default, default, err