Scripting Runtime Upgrade

[BlackPete]

I have a question about Unity’s philosophy in going forward with the scripting runtime upgrade: Will breaking changes be actively encouraged or discouraged?

IMO, it should be actively encouraged, even at the expense of (easily) upgrading a project to 2017.1.

Upgrading .Net is a major enough upgrade that I’m not sure it’d make sense to try to maintain some sort of an upgrade path anyway. I’d want to make sure to bring over project components over on a case-by-case basis to ensure everything still worked, or fix/change things accordingly.

One example that comes to mind is a breaking change in how closure captures work in C# 5. I’d want to go over my scripts again with a fine tooth comb to ensure nothing broke in how my captures were handled. It’s unfortunate in a huge project, but it’s a necessary evil IMO.

[hippocoder]

I believe that upgrading sensitive projects is discouraged, by all developers worldwide. You should only upgrade if you need something in a newer build such as a vital bug fix or for performance.

The idea about scripting upgrading is to ease the pain for users and allow Unity to depreciate features / make quicker changes with the new release model. It is even happening for shaders now.

You should only upgrade if it’s needed, not just for the sake of it though as scripting upgrading is not foolproof and other changes can occur such as with Unity engine behaviour, editor behaviour and so on. Scripting is not the only thing that can break projects or introduce a new bug.

[elbows]

Since the feature docs already available for 2017.1 show that user can select .NET 3.5 or 4.6 on a per project basis, it will be possible to use 2017.1 without upgrading to 4.6. I suspect that once .NET 4.6 for Unity has been out for a good while, has matured and is and considered stable, they will eventually drop the 3.5 support, but that wont happen in 2017.1.

[liortal]

@BlackPete

IMO, it should be actively encouraged, even at the expense of (easily) upgrading a project to 2017.1.

Newer .NET versions aim to be compatible with existing code as much as possible from what i know…
I think that developers should upgrade to the new scripting runtime version expecting nothing to break (or very little changes to happen).

BTW - can you link to how closure captures work in C# 5 ? i’d like to understand what that change means.

[BlackPete]

@liortal

BTW - can you link to how closure captures work in C# 5 ? i’d like to understand what that change means.

Sure, here ya go:
https://visualstudiomagazine.com/articles/2012/11/01/more-than-just-async.aspx

I’ll quote the relevant bit in case that link goes dead:

The first breaking change involves foreach loops and lambda expressions. In previous versions of the C# compiler, any lambda expression that used the iteration variable within the expression (a “nested lambda expression”) would capture the last value of the iteration variable, not each value through the loop.

Here’s a simple example. I use a foreach loop to build up a list of lambda expressions that will return the iteration value doubled. The loop goes from 0 to 9, so you would expect the result to be 0, 2, 4, 6, 8, 10, 12, 14, 16, 18:

var computes = new List <Func >();
foreach(var i in Enumerable.Range(0,10))
{
computes.Add(() = > i * 2);
}

foreach (var func in computes)
{
Console.WriteLine(func());
}
Run this code before C# 5.0 and you’ll actually get the number 18 printed 10 times. A reference to the loop variable is captured (instead of the value, as you might expect). The result is that when I loop through and call each lambda to double the value, it prints 18 because the last value of “i” in the Enumerable.Range was 9. In C# 5.0, you’ll now see values 0, 2, 4, 6, 8, 10, 12, 14, 16, 18.

[buFFalo94]

i think it’s a good thing because .NET 3.5 is too old and lack of many good features

[makeshiftwings]

@BlackPete

One example that comes to mind is a breaking change in how closure captures work in C# 5. I’d want to go over my scripts again with a fine tooth comb to ensure nothing broke in how my captures were handled. It’s unfortunate in a huge project, but it’s a necessary evil IMO.

Changing foreach in closures is the only real breaking change I remember ever seeing in C#, and I have to agree with them that 99% of the time, anyone putting a foreach in a closure was thinking it worked the new way anyway. If you have to go over your scripts with a fine-tooth comb because it’s full of foreach loops within closures that depend on it incorrectly executing the foreach, I have to wonder what the heck you were trying to code.

[BlackPete]

@makeshiftwings

Changing foreach in closures is the only real breaking change I remember ever seeing in C#, and I have to agree with them that 99% of the time, anyone putting a foreach in a closure was thinking it worked the new way anyway. If you have to go over your scripts with a fine-tooth comb because it’s full of foreach loops within closures that depend on it incorrectly executing the foreach, I have to wonder what the heck you were trying to code.

Hah, no, I didn’t necessarily mean the fine tooth comb is for the closure issue. It’s more about auditing the code to improve it for .Net 4.5 and above (async/await alone would be a total game changer).

That’s actually another reason why I posted the question – to take full advantage of async/await, the API itself may need to be updated to better support the TPL.

So I’m less concerned about maintaining backward compatibility and more about properly supporting modern versions of .Net and C# and taking advantage of “new” features.

[alexzzzz]

There is a breaking change between the old and new Mono libraries. Old and new System.Random given the same seed produce different results.

The same change happened in Net Framework a while ago too, but I don’t remember in which version.

[joncham]

@BlackPete

One example that comes to mind is a breaking change in how closure captures work in C# 5. I’d want to go over my scripts again with a fine tooth comb to ensure nothing broke in how my captures were handled. It’s unfortunate in a huge project, but it’s a necessary evil IMO.

I believe the behavior you are describing was already introduced into Unity 5.5 with the C# compiler upgrade.

[AlanMattano]

@hippocoder

I believe that upgrading sensitive projects is discouraged, by all developers worldwide. You should only upgrade if you need something in a newer build such as a vital bug fix or for performance…

But hippo! In my little experience, I did not upgrade from 4.3 until 5.3 and was a disaster. There were so much scripting errors and visual changes that I was not able to fix and I literally start a new project from scratch. Now I update each big number. 5.4.2 | 5.5.3 | 5.6… and then will try to pass to 2017.1.1 probably losing same asset store plugins. I wish not to make the same mistake. Unity 2017 will be so different?

[hippocoder]

It’s the same for all developers, if you will upgrade, there is always risk to be had. Generally for the first 90% of a project I upgrade alongside, but the last 90% I lock it down