Undefinable return and Branching control feature

[Thaina]

Currently now I think programming language should try to flatten the callback into return types. We have IEnumerable Task Tuple and so on added more and more into each version

There are somethings can be return instead of callback. One I would like to have is nullable reference of valuetype

But nullable was already exist in the system as Nullable<T> struct. So I think I would need to rename this feature as undefinable

In essence this feature try to enforce consumer to use branching syntax that ensure that all the code will not touch the object when it will be undefined by throwing compile error

public undefinable ref Matrix4x4 TryGetTransform(string json)
{
    if(string.IsNullOrEmpty(json))
        return; // return void is syntax for undefined

    // { string name , Matrix4x4 transform }
    var jobj = TryParseJson(json);
    if(jobj == null || string.IsNullOrEmpty(jobj["name"]))
        return;

    var name = (string)jobj["name"];
    if(!refValueDictionary.ContainKeys(name)))
        refValueDictionary[name] = json["transform"].ToObject<Matrix4x4>();

    return refValueDictionary[name];
}

var json = "{ name : \"test\",transform:{ M41 : 0,M42 : 5,M43 : 10 } }";
ref var t0 = TryGetTransform(json); // ERROR : undefinable must be checked
if(TryGetTransform(json) is ref Matrix4x4 t1) // PASS : Can check with is ref T
{
    
}

ref var t2 = TryGetTransform(json) ?? ref new Matrix4x4(); // PASS : Can check with nullable syntax

TryGetTransform(json)?.M44 = 5; // PASS : Can check with nullable syntax. And it return ref so could set a field in it

Except the undefinable new keyword I think we could reuse all nullable syntax to work with undefinable

And I think it could work like async by splitting a function into many sub function. But instead of making a syntax that will be execute once finished. It is a syntax that will make a branch and have compiler ensure that on the call site it will not touch the undefined branch

Might work by transpiled into this

public bool _TryGetTransform(string json)
{
    if(string.IsNullOrEmpty(json))
        return false;

    var jobj = TryParseJson(json);
    if(jobj == null || string.IsNullOrEmpty(jobj["name"]))
        return false;

    return true;
}

public ref Matrix4x4 _ReallyGetTransform(string json)
{
    var name = (string)jobj["name"];
    if(!refValueDictionary.ContainKeys(name)))
        refValueDictionary[name] = json["transform"].ToObject<Matrix4x4>();

    return refValueDictionary[name];
}

var json = "{ name : \"test\",transform:{ M41 : 0,M42 : 5,M43 : 10 } }";
// t0 is error so cannot be transpiled
if(_TryGetTransform(json)) // PASS : Can check with `is ref T`
{
    ref vart t1 = _ReallyGetTransform(json);
}

ref var t2 = _TryGetTransform(json) ? _ReallyGetTransform(json) : ref new Matrix4x4();

if(_TryGetTransform(json))
    _ReallyGetTransform(json).M44 = 5;

Alternative

Actually present alterternative is try/catch that we could just throw error and have the caller try to catch that. But it too slow. It defeat the purpose of using reference ValueType which we want to make it fast in the first place

There also #497 about ref?. Actually this feature could use ref? in place of undefinable keyword if it not cause confusion

Another one is #494 that let we could return reference of any types. Just that we could check that some struct is null. So we could use nullable syntax over it

Last one is Nullable and tuple. Could we make some way to have nullable can return reference?

ps

Are there any problem to use this syntax with iterator or async? async undefinable or IEnumerable of undefinable Matrix something like that

And I think we could use feature in place of nullable for better speed

This feature was revised from dotnet/roslyn#11552 about rework nullable. I think it would be breaking change to just rework nullable to I come up with another syntax instead

But ideally I wish null and nullable should work this way

[lachbaer]

I find this construct rather complicated and confusable. If I had something similar to accomplish like you did in your example, then I would probably code it by hand anyhow.

On the other hand, by thinking about how your wish for a direct ref reference could be done differently, e.g. by using a standard test-doer pattern, I thought that a ref ref Result (2 refs!) or out ref Result could come in handy here.

[svick]

Depending on how ref-like types are going to work (see #472), you might be able to use them here. I think the code could look something like:

[RefLike]
struct NullableRef<T>
{
    private ref T value;

    public ref T Value => HasValue ? ref value : throw new InvalidOperationException();
    public bool HasValue { get; }

    public NullableRef(ref T value)
    {
        this.value = ref value;
        HasValue = true;
    }
}

public NullableRef<Matrix4x4> TryGetTransform(string json)
{
    if(string.IsNullOrEmpty(json))
        return new NullableRef<Matrix4x4>(); // parameterless constructor is syntax for undefined

    // { string name , Matrix4x4 transform }
    var jobj = TryParseJson(json);
    if(jobj == null || string.IsNullOrEmpty(jobj["name"]))
        return new NullableRef<Matrix4x4>(); 

    var name = (string)jobj["name"];
    if(!refValueDictionary.ContainKeys(name)))
        refValueDictionary[name] = json["transform"].ToObject<Matrix4x4>();

    return new NullableRef<Matrix4x4>(ref refValueDictionary[name]);
}

You wouldn't get all the syntactic convenience you're hoping for (no is, ?? or ?.), but it wouldn't require any further changes to the language (assuming ref-like types will actually work something like this).

[lachbaer]

Off topic:

You wouldn't get all the syntactic convenience you're hoping for (no is, ?? or ?.),

I already had some situations where the null-evaluating 'convenience' operators would fit nicely in a structs operating flow. It'd be nice to have them sometimes. Yet I am not done with a well-engineered proposal.

[DavidArno]

Surely #497 already addresses this?