Cannot cast SumType to ?SumType

[sukus21]

Describe the bug

Code: https://play.vlang.io/p/88752cbb95

module main

type SumType = u16 | u32

fn main() {
	a := ?SumType(SumType(u16(0)))
	println(a)
}

This works for non-sum types, so I don't see why it shouldn't work for sum types as well.

Reproduction Steps

Attempt to cast a sum type to an option type containing the same sum type.
This works for other types, but not sum types.

Expected Behavior

I expected to wrap the value in an option type. Instead, I get a compiler error.

Current Behavior

Output:

code.v:6:8: error: cannot cast `SumType` to `?SumType`
    4 | 
    5 | fn main() {
    6 |     a := ?SumType(SumType(u16(0)))
      |           ~~~~~~~~~~~~~~~~~~~~~~~~
    7 |     println(a)
    8 | }
Exited with error status 1

Possible Solution

No response

Additional Information/Context

No response

V version

V 0.4.12 1bf1abd

Environment details (OS name and version, etc.)

|V full version      |V 0.4.12 1bf1abd3f466d3ff00e7d124294e3e14a99b9234
|:-------------------|:-------------------
|OS                  |linux, Debian GNU/Linux 12 (bookworm) (VM)
|Processor           |2 cpus, 64bit, little endian, Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz
|Memory              |0.84GB/2.02GB
|                    |
|V executable        |/home/admin/v/v
|V last modified time|2025-11-20 21:25:31
|                    |
|V home dir          |OK, value: /home/admin/v
|VMODULES            |OK, value: .vmodules
|VTMP                |OK, value: /tmp/v_0
|Current working dir |OK, value: /home/admin/playground
|                    |
|Git version         |git version 2.39.5
|V git status        |N/A
|.git/config present |true
|                    |
|cc version          |cc (Debian 12.2.0-14+deb12u1) 12.2.0
|gcc version         |gcc (Debian 12.2.0-14+deb12u1) 12.2.0
|clang version       |Debian clang version 14.0.6
|tcc version         |tcc version 0.9.28rc 2025-02-13 HEAD@f8bd136d (x86_64 Linux)
|tcc git status      |Error: fatal: detected dubious ownership in repository at '/home/admin/v/thirdparty/tcc'
To add an exception for this directory, call:

	git config --global --add safe.directory /home/admin/v/thirdparty/tcc
 Error: fatal: detected dubious ownership in repository at '/home/admin/v/thirdparty/tcc'
To add an exception for this directory, call:

	git config --global --add safe.directory /home/admin/v/thirdparty/tcc

|emcc version        |N/A
|glibc version       |ldd (Debian GLIBC 2.36-9+deb12u10) 2.36

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.

[jorgeluismireles]

This simpler syntax works and all unwraps works ok:

type SumType = u16 | u32

fn main() {
	a := ?SumType(u16(0))
	if a == none {
		assert false
	} else {
		match a {
			u16 { assert a == u16(0) }
			u32 { assert false }
		}
	}
	b := ?SumType(none)
	if b == none {
		assert true
	} else {
		assert false
	}
}

[sukus21]

This bug has nothing to do with unwrapping, that is not what I am having trouble with. I have a value of type SumType, and I want to cast it to a ?SumType, before returning it from a method. The example code I gave is the smallest possible example of this bug.

[StunxFS]

@sukus21 The error reported here isn't a bug per se. If you want a value of type ?SumType, simply use: ?SumType(u16(0)):

$ cat x.v
module main

type SumType = u16 | u32

fn main() {
        mut a := ?SumType(u16(0))
        println(a)
        a = none
        println(a)
}
$ v run x.v
Option(SumType(0))
Option(none)

[sukus21]

@StunxFS Like I mentioned, the example given is the minimal example to reproduce the code, and is not a "real" program.

The code I'm writing looks something like this:

type SumType = u16 | u32

fn do_some_work() SumType {
	return u16(0) // some value, deoesn't matter
}

fn do_some_optional_work(do_work bool) ?SumType {
	if do_work {
		return ?SumType(do_some_work())
	} else {
		return none
	}
}

I think it's odd that I can't explicitly cast the SumType value to a ?SumType, but when I omit the cast, V casts it to ?SumType implicitly, thanks to the return. That feels like an oversight to me.

[jorgeluismireles]

If your function return type is ?SumType, then is ok to return a simple SumType (or a none). So you don't need to do the conversion SumType to ?SumType.

[JalonSolov]

Exactly. The return type of ?SumType means the return can be either a SumType or none - there is no need to cast anything.

The current error message is also correct - you cannot cast a concrete type to an Option type, as a concrete type can never be anything other than that type, while an Option can be either of 2 different things.

[jorgeluismireles]

Seems not documented that for tests, a simpler syntax for assert options is:

• assert a? == ... when a is expected not none
• assert a == none when a is expected none

type SumType = u16 | u32

fn main() {
	mut a := ?SumType(u16(0))
	assert a? == SumType(u16(0))
	
	a = ?SumType(none)
	assert a == none
}

[imperivox]

Wouldn't it make sense to extend the checker so that explicit casts from a sum type to its option (e.g. SumType -> ?SumType via ?SumType(SumType(...))) are allowed, just like for non sum types?

[JalonSolov]

Actually, I think it's a bug to be able to cast any type to an Option. Something is either already an Option, or it isn't, and there is no casting between the 2.

Even the example @jorgeluismireles gave looks incorrect, to me:

	a = ?SumType(none)

You should be able to assign none to a without a cast, since it is already known that it is a ?SumType from the declaration... and that already works. There is no ?SumType cast required:

type SumType = u16 | u32

fn main() {
	mut a := ?SumType(u16(0))
	assert a? == SumType(u16(0))
	
	a = none
	assert a == none
}

works as expected.

[spytheman]

Option types should have first class support, and that includes converting a concrete value to a compatible option type value. At the time, the explicit cast for ?Sumtype( Sumtype( variant ) ) was not done for simplicity (we had to stabilize other features first).

@sukus21 you are right, thank you.

@JalonSolov about:

Actually, I think it's a bug to be able to cast any type to an Option.

No, you should be able to create option values from all compatible values, and V already does allow for that; it is just done implicitly now.