delete the default zero value in v

[hellolio]

Describe the feature

i hate the default zero value in Go.
the default return zero value makes it hard for me to tell whether it's none or 0

Use Case

module main

fn main() {
    sm := {
        'abc': 'xyz',
        'def': '',
    }
    val1 := sm['bad_key']
    val2 := sm['def']
    println('bad_key is :${val1}--')
    println('def         is :${val2}--')
}


out >>
bad_key is :--
def         is :--

the return result the same

Proposed Solution

module main

fn main() {
    sm := {
        'abc': 'xyz',
        'def': '',
    }
    val1 := sm['bad_key']  // panic: key not found: bad_key
    val1 := sm.get('bad_key', 'bad')  // val1 is 'bad'

    val2 := sm['def']
    
    println('bad_key is :${val1}--')
    println('def         is :${val2}--')
    
}


out >>
bad_key is :bad--
def         is :--

val1 := sm.get('bad_key', '')
add a language feature that makes the code clearer and eliminates implicit assignments
OR :

    val1 := sm['bad_key'] or {
        println('bad_key is not found')
        'default_value'
    }

Other Information

No response

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

Version used

v 0.4.9

Environment details (OS name and version, etc.)

windows

Note

You can use the 👍 reaction to increase the issue's priority for developers.

Please note that only the 👍 reaction to the issue itself counts as a vote.
Other reactions and those to comments will not be taken into account.

[huly-for-github]

Connected to Huly®: V_0.6-22336

[hellolio]

propose removing the default return zero value in all code of v

[kbkpbot]

It's also possible to use an or {} block to handle missing keys:

mm := map[string]int{}
val := mm['bad_key'] or { panic('key not found') }

You can also check, if a key is present, and get its value, if it was present, in one go:

m := {
	'abc': 'def'
}
if v := m['abc'] {
	println('the map value for that key is: ${v}')
}

[hellolio]

it seems that the developers do not want a panic, so they chose to provide a default value of 0 to prevent it
if that's the case, this seems to be a choice between panic and implicit assignment, maybe I should close this issue

[hellolio]

if this issue occurs in a production environment, the program should ideally throw an exception to alert the maintainer. However, it chooses to return a zero value, which ends up contaminating my data. by the time I notice it, it might be very difficult to clean up the zero values. on the other hand, if an exception were thrown, I would be able to spot the issue immediately and ensure that the data remains uncontaminated

additionally, the use of or {} typically handles cases where the return value is !T, but here the return value is processed as a zero value, which is inconsistent with the general logic of v

[JalonSolov]

It is very clearly marked in the documentation (under https://docs.vlang.io/v-types.html#maps):

If a key is not found, a zero value is returned by default:

then it goes on to tell you

It's also possible to use an or {} block to handle missing keys:

Changing this behavior now would essentially cause ALL OF V to break. I don't see any reason to completely break the language to change documented behavior.

[hellolio]

It is very clearly marked in the documentation (under https://docs.vlang.io/v-types.html#maps):

I know, but you didn’t address the issue I raised.

Changing this behavior now would essentially cause ALL OF V to break. I don't see any reason to completely break the language to change documented behavior.

Since V is not yet at 1.0, why worry?
I believe everything can be discussed before 1.0. We shouldn’t carry regrets into 1.0.

[medvednikov]

It's two different philosophies. The Go approach and the Rust approach.

It was already decided that we'll allow forcing the Rust approach via a struct anntribute. It may have been implemented already.

[hellolio]

That's great, I'd really appreciate it if you could share any related links, I'll keep an eye on the relevant updates

[jorgeluismireles]

IMHO, panics are for programmers using other programmers libraries not for the program end users. A panic for a missing map element can happen in normal program operation and end user would receive a very cryptic panic. Maps returning empty string and string returning zero when string is not a number are fast solutions to have a "default". For instance, println("bad".int()) prints zero for your convenience, but if your really want to catch a non-number then you use strconv package.

[hellolio]

What you said in the first half is correct, but please understand my point—I don’t want the data to be corrupted. Moreover, the author has already decided to adopt the Rust solution, which means there will be no panics, but rather compile-time checks.
I think this is the answer both you and I want.

[hellolio]

To reiterate the point I made at the beginning of the issue, I really dislike the way Go handles default zero values. It’s implicit. For example, if you fetch data from a database and get a 0, you can’t tell if it represents none or 0. There’s no indication at all, and the program doesn’t give any warning. None and 0 represent completely different meanings, but the program simply ignores this, which is quite scary. This is one of the reasons why I’m paying attention to new languages outside of Go.

[jorgeluismireles]

These two functions are in V builtin module:

pub fn (s string) bool() bool {
	return s == 'true' || s == 't' // TODO: t for pg, remove
}
...
pub fn (s string) int() int {
	return int(strconv.common_parse_int(s, 0, 32, false, false) or { 0 })
}

Their simplicity maybe produce strange results. Next code compiles ok

assert 'TRUE'.bool() == false // default returned
assert '1_'.int() == 0 // default returned
assert '1a'.int() == 1 // "corrects" user typo

I assume they are not intended to be used for database integrity operations but as helpers to return a default when is harmless. For requesting an user to enter exactly true and exactly 1 we should use V Results to prevent the defaults.

Maybe what is missing is document more explicity that such helper methods should return "unexpected" defaults.