koobas.hobune.stream
C# - Doesn't Unity support Expression Bodied Properties?
I have this line of code in C#.
private static float Width => 0.015f;
Unity is complaining about the following:
Unexpected symbol `=>' in class, struct, or interface member declaration
Doesn't Unity support Expression Bodied Properties?
It's a new amazing feature of C# 6.0
@Cameron860 @Bunny82 I have this line of code:
public static float4x4 identity => new float4x4 { m0 = new float4(1.0f, 0.0f, 0.0f, 0.0f), m1 = new float4(0.0f, 1.0f, 0.0f, 0.0f), m2 = new float4(0.0f, 0.0f, 1.0f, 0.0f), m3 = new float4(0.0f, 0.0f, 0.0f, 1.0f) };
For what I should to change this?
$$anonymous$$y error is "Feature `expression bodied members' cannot be used because it is not part of the C# 4.0 language specification´
Thanks!
Just create a normal property:
public static float4x4 identity {
get {
return new float4x4 {
m0 = new float4(1.0f, 0.0f, 0.0f, 0.0f),
m1 = new float4(0.0f, 1.0f, 0.0f, 0.0f),
m2 = new float4(0.0f, 0.0f, 1.0f, 0.0f),
m3 = new float4(0.0f, 0.0f, 0.0f, 1.0f) };
}
}
You can now change framework: (Project Settings > Player > Other Settings) 
@israelg99 I feel your pain. Sadly, there's not a lot you can do about it unless you can write a lot of your code on a seperate library outside of Unity.
Many of the new C# 6.0 features can be used with .NET 3.5 framework target code because they're just syntactic sugar that lets you type less. The compiled CLR (Common Language Runtime) bytecode is identical. Alas, Roslyn (which is what Microsoft named their new C# 6.0 compiler) is only currently being used in Visual Studio. The .NET Framework version (2.0, 3.5, 4.0 etc) and the C# version aren't the same thing.
If you write your code as a seperately compiled DLL and use Visual Studio you can use expression bodies and all the other C# 6.0 features (those supported in the .NET 3.5 target at least) with Unity because it's all compiled to valid .NET 3.5 Framework bytecode inside the DLL and Unity won't complain. However, Unity's built in automatic compiler is old and won't understand the newer syntax. I hope they update it , Microsoft already have Roslyn running on a Mac with Visual Sdutio Code.
I think the only .NET 3.5 features that unity doesn't support are largly based around IL injection, code emit and dynamic compilation (Expression classes etc).
I generally agree that some newer features would be quite nice to have in Unity, however those expression properties aren't one of them. It doesn't save much and just makes it harder to convert it into a full property if needed. They can only be used for read-only properties. They also can be overlooked easily.
This does the same thing:
private static float Width { get { return 0.015f; } }
as this:
private static float Width => 0.015f;
In this particular case it would be easier and better for performance to use a simple constant as it's not always given that simple properties are always inlined.
private const float Width = 0.015f;
If the "property" should be an instance member you can declare a field as "readonly":
private readonly float Width = 0.015f;
So i wouldn't call those expression properties an amazing feature (as the OP did). The lambda operator itself can make code shorter and easier to read, however the declaration of properties are "standalone" code parts and not inside a long code fragment.
As soon as your "expression" gets more complex you would need some line breaks anyways.
@Bunny82 I think the OP was just showing a $$anonymous$$imal case. I'm generally in favor of less scaffolding if possible (with the exception of if/else brackets, ommiting those is evil I$$anonymous$$O).
I think simplifying the creation of tiny immutable methods/properties that do one thing and do it well was a really good move towards making coders adopt more immutable practices which sadly, most ignore because it takes longer to impliment. Now, not so much.
public string FirstName { get; private set; }
public string LastName { get; private set; }
public string FullName => $"{FirstName} {LastName}";
public string FormalName => $"{FirstName[0]}. {LastName}";
I'm also fairly certain every c# compiler will inline simple getters. As for suggesting it be a constant, that is a behavioural change - the author may intend the property to represent state and hence not want it to be immutable.
no, it doesn't. not sure what the latest version of c# used is (check the docs), but it's definitely not 6.0.
It's an old version of $$anonymous$$ono, kind of a mixture between .NET 2.0 and 3.5 if my understanding/memory is correct.
