The implicit cast to/from a ByRef-like type, such as Span or ReadOnlySpan doesn't help regular conversion operations in PowerShell because the target ByRef-like type cannot be boxed.
But when calling methods via Expression with jitting, Expression.Convert can be used to implicit cast an argument to the Span types before passing to the call and no boxing is involved (see an example below).
var arg = @"e:\abc\def";
var method = typeof(Path).GetMethod(nameof(Path.IsPathRooted), new Type[] { typeof(ReadOnlySpan<char>) });
var body = Expression.Call(method, Expression.Convert(Expression.Constant(arg), typeof(ReadOnlySpan<char>)));
var func = Expression.Lambda<Func<bool>>(body, null).Compile();
var rest = func();
Console.WriteLine(rest);
> True
PowerShell evaluates an Expression tree with interpretation by default, which basically translating Expression tree to pre-defined C# code, so the Expression.Convert might not work like when Expression tree is jitted (haven't looked into it, will investigate that). If it works with the interpreter too (or we can update the interpreter to make it work), we will also need to update the method resolution. We currently use the same "figuring-out-conversion" method for regular conversion in PowerShell as well as when resolving the best matching method. The implicit cast for ByRef-like target types should continue to be "no-conversion" for regular conversion operation, but theoretically acceptable for method resolution.
The implicit cast to/from a ByRef-like type, such as
SpanorReadOnlySpandoesn't help regular conversion operations in PowerShell because the target ByRef-like type cannot be boxed.But when calling methods via Expression with jitting,
Expression.Convertcan be used to implicit cast an argument to theSpantypes before passing to the call and no boxing is involved (see an example below).PowerShell evaluates an Expression tree with interpretation by default, which basically translating Expression tree to pre-defined C# code, so the
Expression.Convertmight not work like when Expression tree is jitted (haven't looked into it, will investigate that). If it works with the interpreter too (or we can update the interpreter to make it work), we will also need to update the method resolution. We currently use the same "figuring-out-conversion" method for regular conversion in PowerShell as well as when resolving the best matching method. The implicit cast for ByRef-like target types should continue to be "no-conversion" for regular conversion operation, but theoretically acceptable for method resolution.