Bringing TypeConverter to C# editor

[a44281071]

In XAML, TypeConverter refers to a converter provided by the XAML framework, which is used to convert string-form property values into specific types of objects within the .NET framework. These converters are automatically applied.

In C#, this automatic conversion feature is lacking, but there is a similar feature, User-defined explicit and implicit conversion operators.

These two features have their own advantages and disadvantages, but TypeConverter has more significance for future language service features. Below, we will refer to TypeConverter as TC and explicit and implicit conversion operators as EIC for convenience in later comparisons.

EIC (explicit and implicit conversion operators)

• In terms of writing, when defining an object, it has less code and exists as a member of the object.
• When used, it is almost imperceptible; if you are not aware of it, you might not even know it exists, and perhaps you can only find out by viewing the source code.
• It is only used for conversion from one type to another, and when used, you must comply with this agreement and cannot add any additional functionality.
• Because it cannot add functionality, the language service will not have more support for it.

TC (TypeConverter)

• In terms of writing, it is an additional object defined and attached to the original object as an attribute, which results in more code.
• When used (for example, in XAML), you will perceive its existence more, such as width being represented as 1024|auto, which corresponds to specifying a definite width or not specifying a value Double.NaN;
• Because it exists as an attribute object, we can take it as an additional feature, conveniently adding more conversion features.
• The language service can have more support, such as existing input content availability, code hints, and even source code generators.

What would bringing TC functionality into C# bring?

• Our input code content is actually all strings. Everyone has enjoyed the increasing joy brought by the conciseness of C# upgrades. So, the less we input, the happier we will be, which is absolutely correct.
• Our code review will become more difficult due to the volume of code. For repetitive code, in addition to increasing understanding difficulty, it is also more prone to errors.
• Our value transmission will have a OneOf situation. The example above (1024|auto) demonstrates that if you define a parameter in C# to accept a value, you may add more mental burden before or after entering the method. If this can be solved by language services, that would be great.
• Source code generators are great now. If we can generate some strangely written code through simple words, that would be a happy thing.

How to introduce this feature into C#?

• We can input a short word or phrase and generate potentially complex objects or even strangely written statements through code generators.
• We must distinguish the input word or statement from the existing syntax because it is neither a string nor a keyword. For example, we can use Keys.Oem3 (~), auto to indicate Double.NaN, #FF101010 to indicate Color or Brush.

More Demonstrations

The simplest demonstration

// TC
if (myColor is `White` or `Black`)
{
    // white or black
}

// source
if (myColor is Colors.White or Colors.Black)
{
    // white or black
}

Clearly used to reduce code volume

RowDefinition row1 = myGrid.RowDefinitions[0];

// TC
row1.Height = `auto`;
row1.Height = `150`;
row1.Height = `1*`;

// source
row1.Height = GridLength.Auto;
row1.Height = new GridLength(150, GridUnitType.Pixel);
row1.Height = new GridLength(1, GridUnitType.Star);

The following may be the thing WPF players want most

// TC
myGrid.RowDefinitions = `*,*,*`;

// source
RowDefinition rowDef1 = new RowDefinition();
RowDefinition rowDef2 = new RowDefinition();
RowDefinition rowDef3 = new RowDefinition();
RowDefinition rowDef4 = new RowDefinition();
myGrid.RowDefinitions.Add(rowDef1);
myGrid.RowDefinitions.Add(rowDef2);
myGrid.RowDefinitions.Add(rowDef3);
myGrid.RowDefinitions.Add(rowDef4);

Perhaps more advanced syntax may appear, which may not only have code hints but also more complex source code generators

int[] numbers = [2, 4, 6, 8];
int nu = 2;

// TC
if (nu is `in numbers`)
{
    // numbers.Contains(2)
}

// source
if (numbers.Contains(nu))
{
    // numbers.Contains(2)
}

// TC
dynamic builder = `2,3,4`;
Cube cube = builder;
Vector3D v3d = builder;
Version v3 = builder;

// source
Cube cube = new(2, 3, 4);
Vector3D v3d = new(2, 3, 4);
Version v3 = new(2, 3, 4);

For other industries, such as gaming, this may lead to a more comfortable experience.

// TC
Sprite2D sprite2D = `#rootNode`;  // we can add 'Language services' support.

// source
Sprite2D sprite2D = GetNode<Sprite2D>("#rootNode");

// is better than EIC, because we have 'Language services'
Sprite2D sprite2D = $"Sprite2D";  // String does not have code prompt function

[huoyaoyuan]

The entire concept of "conversion" is about conversion at runtime, not compile time. The language should be more interested in conversions at compile time and runtime conversions are discouraged. XAML needs TypeConverter because it needs to deserialize objects from stream with strings.

• Our input code content is actually all strings. Everyone has enjoyed the increasing joy brought by the conciseness of C# upgrades. So, the less we input, the happier we will be, which is absolutely correct.

This is actually the major down side. Strings are untyped, requires parsing overhead, and can be misspelled. Building a complete parser of string format is heavy and hard work.

Moreover, strings are naturally linear and unstructured, makes nesting very complex.

---

Instead, the C# language should be more interested in providing building syntax for different sort of types. Taking the each examples:

myColor is `White` or `Black`

This is about simplified or customized literal declaration. Specific to enums, there's already proposal #8641 and #4479, allowing syntax myColor is White or Black or myColor is .White or .Black.

row1.Height = `1*`;

This needs to run more customized syntax parser. When integrated with language, the bar is much higher than integration with application framework. The code needs to be directly executed by compiler, to have graceful error reporting and handling, etc.

If there's no such compile-time integration and everything is converted at runtime, it will have no difference than a shorthand to static factory method, like .Parse("1*").

myGrid.RowDefinitions = `*,*,*`;

This is the complex, nested case. The outer level is solved collection expression and the proposal is reduced into [`*`, `*`, `*`].

With composability, different levels can evolve separately, for example you can do [..otherGrid.RowDefinitions, pseudosyntax(`*`)] without bothering support from the whole RowDefinitionCollection parsing, and with whatever way to construct individual RowDefinitions.

dynamic builder = `2,3,4`;

This is the worst example with no interest. In the example, the different types are totally unrelated and happen to accept three numbers. The "unbuilt" source of `2,3,4` is just a plain tuple (2, 3, 4), and can be easily used if a conversion is defined for each type.

The language feature benefiting this would be extension conversion operators. Imagine you can define this:

public class BuildingExtensions
{
    extension(Cube) { public static implicit operator Cube((int, int, int) tuple) => new(tuple.Item1, tuple.Item2, tuple.Item3); }
    extension(Vector3D) { public static implicit operator Vector3D((int, int, int) tuple) => new(tuple.Item1, tuple.Item2, tuple.Item3); }
    extension(Version) { public static implicit operator Version((int, int, int) tuple) => new(tuple.Item1, tuple.Item2, tuple.Item3); }
}

if (nu is `in numbers`)

This one is even worse example. Parsable logic expression is immediately a new language. The examples are LINQ expressions and interpolated strings, which are integrated very deeply in the language, in order to be composable with other features.

Sprite2D sprite2D = `#rootNode`;

This one is in fact unclear to me, whether constructing a new node with label or finding the corresponding node.

---

A general-purpose language is more interested about composable blocks, instead of opaque boxes of DSL.
If you want to translate strings into arbitrary code entities and interact with more code elements, it's the most complex thing of creating new language dialects. In real world there are very low chance for features designed in-the-wild to work well. Regex source generator is really a rare case, which has well-supported syntax, no interaction with other code and conventional method boundary.
If you want to translate strings into arbitrary objects like XAML, it's the most boring thing of just shorthand of factories.

XAML is more a DSL, with special interest of given types. Type converters are just deserializers. I do write XAML a lot, and are always struggling with the poor composability of the object or binding notations.

[a44281071]

Yeah, so this is code gen like TypeConverter.