Allow [ParamCollection]

[timcassell]

I maintain a library that supports both nuget and Unity, and I want to add support for params ReadOnlySpan<T>. Unity doesn't yet support C# 13, so I thought I could just manually declare and use the ParamCollectionAttribute, which works in Unity thanks to the older compiler (the attribute means nothing on older compilers), but errors with latest sdk and in Visual Studio (even when targeting older LangVersion and TargetFrameworks).

CS0674: Do not use 'System.ParamArrayAttribute'/'System.Runtime.CompilerServices.ParamCollectionAttribute'. Use the 'params' keyword instead.

I tried #pragma warning disable CS0674, but it had no effect.

The only alternative is to clutter the code with #if/#endif around all params usages, which is ugly and not future-proof to whenever Unity decides to upgrade its language version (there are no preprocessor symbols for LangVersion), and it forces me to target C# 13 when I only want to target C# 7.3 for netstandard2.0 (for feature parity with old Unity versions).

[CyrusNajmabadi]

when I only want to target C# 7.3 for netstandard2.0

If you only can do that, them adding this attribute would not help, as it would still require an updated language version to support it.

[timcassell]

when I only want to target C# 7.3 for netstandard2.0

If you only can do that, them adding this attribute would not help, as it would still require an updated language version to support it.

On the consumer's side, not on the library side.

[CyrusNajmabadi]

The consumer won't be able to use this if they're on 7.3. Consumption of params-ros will be need a modern compiler and lang version

[timcassell]

Yes, I'm aware of that. My point is I want the library to make it available for consumption without caring whether the consumer actually can use it or not. If they are using C# 13 or later, they can use it. If they are using C# 12 or older, they can't. The library doesn't care.

[CyrusNajmabadi]

If you want to make the library available without caring if it can be consumed, just use the latest version of c# and the latest lang features.

[timcassell]

It's not so simple when also supporting Unity. I have to do this ugliness

public ReturnType<T> M<T>(
#if !UNITY_XXXX_X_OR_NEWER
    params
#endif
    ReadOnlySpan<T> input)
{
    ...
}

and then update the library with new preprocessor symbols in the future when Unity adds C# 13 support.

It would be much simpler and cleaner to just do

public ReturnType<T> M<T>([ParamCollection] ReadOnlySpan<T> input)
{
    ...
}

[CyrusNajmabadi]

It would be much simpler and cleaner to just do

public ReturnType M([ParamCollection] ReadOnlySpan input)

But you'll only get that with the new compiler, using some new lang versino. So that won't work anyways, since you're going to be limtied "when also supporting unity".

[timcassell]

But you'll only get that with the new compiler, using some new lang versino. So that won't work anyways, since you're going to be limtied "when also supporting unity".

What do you mean? I declare the attribute in my code instead of the compiler synthesizing it. The only thing I need is for the compiler to not block me from using it.

[CyrusNajmabadi]

The only thing I need is for the compiler to not block me from using it.

You would still need a new compiler for that, and a new lang version where this new rule was allowed in. We still have to follow the rule that code compiles the same way if you're on an older lang version. So since it errors before, it still needs to error if we were to add support for this.

[timcassell]

Why does it need to error? Older compilers are silent to this attribute. It could be downgraded to a warning that I could suppress at least?

[CyrusNajmabadi]

Why does it need to error?

To match the behavior of prior compilers. That's the point of langauge versions with new compilers.

Imagine if we removed the error in Compiler version 15. A team has two developers. One is on Compiler v14 running lang v14. Another dev runs Compiler v15 with lang v14. Now tjhey get different behavior. One sees an error, the other does not.

You've violated the main goal of having lang versions and allowing people to have different compilers.

In order for this to work, you'd need both the new compiler, and a new lang version. But if you're using a new compiler, and the later lang version, you can just use params in the first place.

[timcassell]

But that behavior is already different between older versions and current version. Older compiler doesn't error while new one does.

[timcassell]

Also I don't see why it's a bad thing to relax errors. It's been done plenty of times in the past.

[CyrusNajmabadi]

It's been done plenty of times in the past.

Without rev'ing the language version?

[timcassell]

Without rev'ing the language version?

I don't know, I haven't paid that much attention to Roslyn. But the current compiler already violates that when it comes to this attribute. Targeting older lang version does not make the error go away.

[CyrusNajmabadi]

I'll leave it to others to decide if it's ok to relax this without a new lang version. But it still seems odd to me. :)

[huoyaoyuan]

Old versions of compilers see ParamsCollectionAttribute as a plain attribute. New compiler always treats it as a part of params collection feature, and disallows explicit usage. It's just uncommon for old compiler to ever see the attribute, because using old compiler on new target framework is blocked by toolchain.

I think the real problem is that Unity uses its own forked C# compiler. Typically in .NET, libraries are shipped in binary. Library author can use one highest compiler version to target all different frameworks, and control the exposed language feature with one compiler.

[timcassell]

AFAIK Unity doesn't use a forked compiler, they just lock down the version of the compiler that is used. They only use a forked Mono, but they've been using Roslyn since C#7.

The problem is really that it needs to use source code for full compatibility. Hoping that will change when they add CoreCLR...

[RikkiGibson]

I think [ParamCollection] is disallowed for explicit usage in the newer compiler, in part because allowing it would complicate the process of enforcing the collection is valid. It's like if [IsReadOnly] were explicitly used on a field.

Does Unity really not give any way of pinning the compiler to a different version? e.g. using Microsoft.Net.Compilers.Toolset package? This would also be unsupported, but, might allow you to achieve what you want more simply.

[timcassell]

Does Unity really not give any way of pinning the compiler to a different version?

I don't think so, and even if it did, I can't expect users of my library to change the compiler version that Unity offers by default.

[RikkiGibson]

The purpose of that would be allow you to write params Collection..., not for your users to do anything with it.

[timcassell]

But my users have to use the source code. So that won't work.