Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

map access or block behavior is inconsistent with the rest of the language #20391

Closed
juan-db opened this issue Jan 5, 2024 · 3 comments · Fixed by #20544
Closed

map access or block behavior is inconsistent with the rest of the language #20391

juan-db opened this issue Jan 5, 2024 · 3 comments · Fixed by #20544
Labels
Bug This tag is applied to issues which reports bugs.

Comments

@juan-db
Copy link
Contributor

juan-db commented Jan 5, 2024

Describe the bug

Please see the code snippets with commentary below.

Reproduction Steps

Try to compile the following code:

fn get_value(m map[string]int, key string) ?int {
	return m[key] or { none }
}

Expected Behavior

The program to compile successfully. This would be consistent with how or blocks behave in other contexts, e.g.:

fn even_or_none(i int) ?int {
	return if i % 2 == 0 { i } else { none }
}

fn useless_fn(i int) ?int {
	return even_or_none(i) or { none }
}

Current Behavior

The compiler gives an error.

map.v:2:21: error: `or` block must provide a value of type `int`, not `none`
    1 | fn get_value(m map[string]int, key string) ?int {
    2 |     return m[key] or { none }
      |                        ~~~~
    3 | }

Possible Solution

No response

Additional Information/Context

One of the users on Discord pointed out, I can use or { return none } instead of just or { none } and it'll work fine, but the second return seems redundant.

fn get_value(m map[string]int, key string) ?int {
	return m[key] or { return none }
}

V version

V 0.4.3 e19b2dd

Environment details (OS name and version, etc.)

V full version: V 0.4.3 5b96d8d.e19b2dd
OS: macos, macOS, 14.2.1, 23C71
Processor: 11 cpus, 64bit, little endian, Apple M3 Pro

vexe mtime: 2024-01-05 00:03:27

vroot: OK
VMODULES: OK
VTMP: OK

Git version: git version 2.39.3 (Apple Git-145)
Git vroot status: weekly.2024.01.test2-1-ge19b2dd4
.git/config present: true

CC version: Apple clang version 15.0.0 (clang-1500.1.0.2.5)
thirdparty/tcc status: thirdparty-macos-arm64 a668e5a0

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.

@juan-db juan-db added the Bug This tag is applied to issues which reports bugs. label Jan 5, 2024
@shove70
Copy link
Contributor

shove70 commented Jan 5, 2024

No, it's not about V.

fn get_value(m map[string]int, key string) ?int {
	return m[key] or { none }  // The or block here is map specific and is where we handle when the key doesn't exist
	                           // The priority of this or block is to the map, not to the previous return
}
fn even_or_none(i int) ?int {
	return if i % 2 == 0 { i } else { none }
}

fn useless_fn(i int) ?int {
	return even_or_none(i) or { none } // The or block here is the option that handles the return value of fn even_or_none()
}

They're not the same

@shove70
Copy link
Contributor

shove70 commented Jan 5, 2024

fn get_value(m map[string]int, key string) ?int {
	return m[key] or { return none }
}

So it works

@juan-db
Copy link
Contributor Author

juan-db commented Jan 5, 2024

Result behaves the same as Option.

fn even_or_error(i int) !int {
	return if i % 2 == 0 { i } else { error('${i}') }
}

fn useless_fn(i int) ?int {
	return even_or_error(i) or { none }
}

I can't think of another example that uses or syntax. So why should map behave differently from Result and Option?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug This tag is applied to issues which reports bugs.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants