Missing coercion in ternary operator

[bbannier]

When using a Null as a value in a ternary operator it does not seem to be coerced to the correct type.

module nil;

function g(): optional<uint64> {
	return True ? optional(10) : Null;
}

I would expect Null to be coerced to an optional<uint8> here but instead I see

$ spicyc -j nil.spicy
[error] nil.spicy:4:9: types of alternatives do not match in ternary expression (optional<uint<64>> vs. <null type>)
[error] spicyc: aborting after errors

At least in this example we should be able derive some target type from the first branch of the ternary. The same approach seems to break down for ternaries where Null appears as first branch; if we do not want to change how types for ternaries are resolved (e.g., from the use of the whole expression), we might need to introduce support for users to specify a type of a Null (currently we only support creating set optionals -- still with implicitly derived type).

The workaround is to use a typed Null value,

function g(): optional<uint64> {
	local nil: optional<uint64> = Null;
	return True ? optional(10) : nil;
}

[rsmmr]

On further consideration, I think this is ok to leave as is, I don't think this actually a bug, C++ has the same issue when returning an optional vs std::nullopt through a ternary. I'll go ahead and close, reopen if you disagree.

[rsmmr]

That said, #1143 needs coercion for ternary, too, so that fix will address this too.