C# 12 - ref readonly 매개변수
자, 이제 드디어 C# 12의 마지막 8번째 개선 사항입니다. ^^
ref readonly parameters
; https://github.com/dotnet/csharplang/issues/6010
; https://github.com/dotnet/csharplang/blob/main/proposals/csharp-12.0/ref-readonly-parameters.md
Language Feature Status
; https://github.com/dotnet/roslyn/blob/main/docs/Language%20Feature%20Status.md#c-120
다른 7개와는 달리, 현재(2023-10-25) Visual Studio 2022의 Preview 버전으로만 테스트할 수 있습니다.
ref readonly는 기존에도 타입의 멤버 변수, 로컬 변수, 메서드의 반환 타입으로 사용하는 것이 가능했는데요,
public ref struct MyStruct
{
public ref readonly int Value;
public MyStruct(int value)
{
ref readonly int localVar = ref GetValue();
}
private ref readonly int GetValue()
{
return ref Value;
}
}
C# 12부터는 이것을 메서드의 매개변수 유형에도 사용할 수 있게 되었습니다.
namespace ConsoleApp1;
internal class Program
{
static void Main(string[] args)
{
int i = 5;
StructType st = new StructType { Value = 5 };
ProcessRefReadOnly(ref st);
}
public static void ProcessRefReadOnly(ref readonly StructType instance)
{
}
}
public struct StructType
{
public int Value;
public void Increment() { Value++; }
}
기존의 ref 유형과 동일하지만 readonly이기 때문에 읽기 전용이라는 차이점만 있습니다. 이로 인해 다음과 같이,
public static void ProcessRefReadOnly(ref readonly StructType instance)
{
instance = new StructType { Value = 10 }; // readonly이므로 ref 참조에 대해 새로운 값 대입 불가능
instance.Value = 10; // readonly이므로 멤버 변경 불가능
instance.Increment(); // 호출은 가능하지만 defensive copy 발생
}
직접적인 매개변수의 대입과 멤버 값 변경은 컴파일 단계에서 허용하지 않습니다. 반면, 메서드 호출의 경우에는 컴파일러가 (내부 코드에서 값을 변경하는지 알 수 없으므로) 허용은 하지만 단지
defensive copy가 발생하므로 잘 알고 사용해야 합니다. (눈치채셨겠지만, 이러한 규칙은 in 변경자와 정확히 일치합니다.)
이상적으로는 ^^; ref readonly에 대한 설명은 저것으로 끝일 수 있었습니다. 문제는, C# 개발자들이 ref readonly 이전에 "in 변경자"를 이미 만들었다는 점입니다.
C# 7.2 - 메서드의 매개 변수에 in 변경자 추가
; https://www.sysnet.pe.kr/2/0/11525
실제로 저는 저 글을 쓰면서 in의 의미가 사실상 "ref + readonly"라고 설명했습니다. 그런데 ^^; C# 12에서 정확히 그 문구에 해당하는 "ref readonly" 변경자를 추가한 것입니다.
게다가 in 변경자는 여전히 "ref + readonly"의 의미를 갖고 있는 것이 맞습니다. 그럼 도대체 왜? in이 있는데도 불구하고 굳이 "ref readonly"를 새롭게 추가했을까요?
왜냐하면, in 변경자가 "ref + readonly"와 동일한데도 불구하고 "ref"의 원칙에 위배되는 기능을 하나 갖고 있기 때문입니다.
namespace ConsoleApp1;
internal class Program
{
static void Main(string[] args)
{
int i = 5;
ProcessIn(i); // "in" 없이도 전달 가능
ProcessIn(in i); // in을 명시하는 것도 가능
ProcessIn(5); // 값을 전달하는 것도 가능
ProcessRef(ref 5); // 값 전달은 컴파일 오류 - error CS1510: A ref or out value must be an assignable variable
}
public static void ProcessIn(in int instance)
{
}
public static void ProcessRef(ref int instance)
{
}
}
ref가 갖는 참조의 의미에 따라 원래는 값을 직접 전달하는 것은 가능하지 않습니다. 하지만, in 변경자의 경우에는 어차피 readonly라는 특성을 감안해 내부 코드에서 대입을 허용하지 않을 것이므로, 어쩌면 C# 개발자들은 컴파일을 허용해도 무방할 것이라 생각했을 것입니다.
그래서 다시 "ref"의 원칙에 맞게 값 전달을 (막을 수는 없고) 경고하는 "ref readonly"가 추가된 것입니다.
ProcessRefReadOnly(5); // ref readonly에 값을 전달하는 경우 CS9193 경고 발생
// warning CS9193: Argument 1 should be a variable because it is passed to a 'ref readonly' parameter
일단, 문서상으로는 저것 때문에 추가했다고는 하지만, 아마 현실적으로는 추가할 수밖에 없었을 것입니다. ^^ 왜냐하면, 이미 "in"은 "ref + readonly"의 의미를 갖고 있었으므로 기왕에 구현했으니 일관성을 가져가는 것이 좋았을 것입니다. 그런 의미에서, 기존에 가능했던 "ref readonly" 코드를 아래와 같이,
public ref struct MyStruct
{
public in int Value;
public MyStruct(int value)
{
in int localVar = ref GetValue();
}
private in int GetValue()
{
return ref Value;
}
}
in으로 통일하는 것도 우스웠을지도 모릅니다. 암튼, 이런 것까지 감안하면 그동안의 문법을 한번 리부팅하는 (C#이 아닌) CSharp과 같은 식의 언어로 내놓는 것이 어떨까... 하는 생각을 갖게 됩니다. CSharp 언어에서는 "in" 예약어는 없어지고 "ref readonly"만 있는 식으로. ^^
개인적인 판단으로, 이것은 C# 개발팀의 성급함에서 온 실수라고 봅니다. 처음부터 ref readonly를 추가했어야 하고, 값 전달은 "ref"의 원칙에 맞게 (경고가 아닌) 오류로 처리했어야 합니다.
물론, C# 7.2 시절에는 "ref readonly"까진 필요하지 않았었고, 그 와중에 "값 형식(struct)"에 대한 성능 보완을 추진하다 보니 "in 변경자"의 사양은 적절했습니다. 단지 결과적으로 그것은 섣부른 결정이 되었고, 그로 인해 C# 12에서 "ref readonly"가 추가된 것입니다.
그런 의미에서, 아마도 처음부터 "ref readonly"를 구현했다면 "in"은 없었을 것입니다.
아무튼, in과 ref readonly는 IL 코드상으로 봐도 별다른 차이점이 없습니다.
public static void ProcessIn([IsReadOnly] [In] ref StructType instance)
{
}
public static void ProcessRefReadOnly([RequiresLocation] [In] ref StructType instance)
{
}
보는 바와 같이 "in 변경자"의 메서드 정의에 IsReadOnly 대신 (의미상으로는 IsReadOnly도 포함한)
RequiresLocation 특성을 쓴 것이 "ref readonly" 변경자입니다. 또한, "[RequiresLocation]" 특성은 "
modopt"로 선택적이어서 이것을 이해하지 못하는 낮은 버전의 컴파일러에게는 "ref readonly" 매개변수는 "in" 매개변수와 동일하게 해석됩니다.
따라서, "ref readonly"와 "in" 매개변수를 갖는 동일한 이름의 메서드는 재정의할 수 없습니다.
public static void ProcessRef(ref int instance)
{
}
public static void ProcessRef(in int instance) // ref와 함께 정의할 수 있지만,
{
}
public static void ProcessRef(ref readonly int instance) // in과 ref readonly는 구분하지 못하므로,
// 컴파일 에러 - CS0663 '...' cannot define an overloaded method that differs only on parameter modifiers 'in' and 'ref readonly'
{
}
자, 이제 하나의 ref는 총 4개(ref, ref readonly, in, out)의 변경자로 나뉘게 되었습니다. 그리고, 해당 매개변수를 갖는 메서드를 호출하는 측에서도 다음과 같이 다양한 규칙을 적용해 변경자를 지정할 수 있습니다.
|
|
메서드 측 매개변수
|
|
ref
|
ref readonly (C# 12)
|
in
|
out
|
|
호출 측 변경자 표시
|
ref
|
허용
|
허용
|
경고(C# 11 이하 오류)
|
에러
|
|
in
|
에러
|
허용
|
허용
|
에러
|
|
out
|
에러
|
에러
|
에러
|
허용
|
|
변경자 없이 전달
|
에러
|
경고
|
허용
|
에러
|
새롭게 추가된 "ref readonly"의 경우 간단하게 다음과 같이 코드로 재현할 수 있습니다.
namespace ConsoleApp1;
internal class Program
{
static void Main(string[] args)
{
int value = 5;
ProcessRefReadOnly(ref value); // 허용
ProcessRefReadOnly(in value); // 허용
ProcessRefReadOnly(out value); // 에러: error CS1615: Argument 1 may not be passed with the 'out' keyword
ProcessRefReadOnly(value); // 경고: warning CS9192: Argument 1 should be passed with 'ref' or 'in' keyword
}
public static void ProcessRefReadOnly(ref readonly int instance)
{
}
}
또한, "in" 변경자의 경우 기존에는 호출 측에서 "ref"를 지정하면 에러가 발생했지만, C# 12부터는 경고 처리로 바뀌었다는 정도만 알고 지나가면 되겠습니다.
namespace ConsoleApp1;
internal class Program
{
static void Main(string[] args)
{
int value = 5;
ProcessIn(ref value); // C# 11 미만의 경우 컴파일 에러
// C# 12 이후부터는 컴파일 경고: warning CS9191: The 'ref' modifier for argument 1 corresponding to 'in' parameter is equivalent to 'in'. Consider using 'in' instead.
}
public static void ProcessIn(in int instance)
{
}
}
마지막으로, 이전에 설명한 대로 "값"을 직접 전달하면 경고가 발생한다는 점에서 rvalue/lvalue 용어를 사용해 다음과 같은 표로 정리할 수 있습니다.
|
|
메서드 측 매개변수
|
|
ref
|
ref readonly (C# 12)
|
in
|
out
|
|
호출 측 값 유형
|
*rvalue
|
에러
|
경고
|
허용
|
에러
|
|
*lvalue
|
에러
|
허용
|
허용
|
에러
|
* Where lvalue means a variable (i.e., a value with a location; does not have to be writable/assignable) and rvalue means any kind of value.
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]