V: Returning non-reference on function with return reference-type results in C error

[danieldaeschle]

What did you do?

struct Abc {
    val int
}

fn test() ?&Abc {
    return Abc{}
}

fn main() {
}

What did you expect to see?
V error that returning var has wrong type (needs to be a reference)

What did you see instead?

/tmp/v/main.13487878201103853006.tmp.c:8102: error: cannot convert 'struct main__Abc' to 'struct main__Abc *'

it doesn't matter which sum type impl is used here.

[medvednikov]

I think this only happens with optional references which arguably shouldn't be allowed at all.

[danieldaeschle]

But we have it in scope.v. It shouldn't result in a C error either.

[danieldaeschle]

Tell me what the expected result should be. Maybe i can fix it. What's the problem with allowing optional references?

[ntrel]

optional references which arguably shouldn't be allowed at all.

References should never be null for null safety. So how do we safely model a null reference if optional references aren't allowed? That seems like a prime case for using an optional.

[medvednikov]

Exactly @ntrel

That's why I think it's unnecessary, and just one of the two should be enough ? or &.

[danieldaeschle]

references can be null?

[danieldaeschle]

https://github.com/vlang/v/blob/master/vlib/v/ast/scope.v#L74

[ntrel]

just one of the two should be enough ? or &.

But an optional shouldn't only hold references. As we have both value types and reference types, it's natural for optionals to be able to hold both. IIUC the union sum types feature is so they can hold values themselves rather than heap allocating - this is often more efficient. Allocating/freeing heap memory can be slow.

[danieldaeschle]

ping @medvednikov forbid reference in Options are not a good solution like @ntrel mention. How should it behave then?

[ntrel]

I think the original code should cause a V error: expected ?&Abc but got Abc.
return &Abc{} should work.