From a13 release notes:
- Editor: Arrays and lists in the inspector can be reorderable now. Use [Reorderable] attribute on your script variables to turn this on.
Just thank you.
20 Likes
Seems strange to require an attribute to make list reorderable. Why not make every list always reorderable? Is there a single valid use case for having non-reorderable list?
8 Likes
@Aras argues it’s too aggressive a change to make default.
https://twitter.com/LegoCylon/status/1268429416192827393
2 Likes
Having implemented reorderable arrays and lists myself (nothing fancy, just the ReorderableList stuff present in Unity), the cost of rendering a reorderable list or array is greater than drawing a regular array. Thus, even if their implementation might very well be more efficient than mine, if you don’t need reorder, you’re paying for something you don’t use, which is really sad imo.
I think it is nice that this is an attribute. Maybe the other way around could have been better (attribute to turn reorder off), but as stated above, this is kind of a big change.
1 Like
Here’s a crazy idea that will take years to implement at the rate that things are going: A preference.
5 Likes
Eh, a preference would mean that you need 2 attributes of which one is always useless.
We have two input systems, one of which is only there for backwards compatibility now. We have three graphics pipelines, two of which no one asked for. We have two programming stacks, one of which benefits a minority of projects and has been in full-time development for 4 years with no end in sight. We need a [CustomEditor(typeof(T))] attribute in addition to inheriting Editor while just inheriting a hypothetical Editor<T> class would accomplish the same thing and allow users to more cleanly implement custom editors.
I think that attribute redundancy should be the least of our worries right now. Granted, the last example is of attribute redundancy.
As for your objection itself, it’s just pick your poison: (non-)Performance by default, or redundancy. Although after testing it myself, I’d be hard pressed to think that this performance impact is noticeable unless you have hundreds of items in your list, at which point the editor has some trouble regardless.
6 Likes
Felt like a too invasive change to do at once. “First make it opt-in, then if everyone likes it make it opt-out” is what we decided to do with this one so far. If majority says “yeah this is great, make it default”, then sure we can do that.
3 Likes
But once 2020.2 releases how do you follow up on that? The majority of people probably won’t be vocal about whether they prefer this as opt in or opt out.
1 Like
A preference in the settings is perhaps an option?
Let’s be honest: We’re stuck forever with however this releases in 2020.2, since the only type of breaking change that Unity does nowadays is removing features altogether. Minor automatically upgradable breaks like this? Nope.
It has to be decided as a global attributeless change or as a preference before 2020.2 releases. My vote is on the former: With 1000 items, I saw a <1% difference in CPU usage and barely any in performance between reorderable and non-reorderable. I can’t think of a use case for serializing a list with over a thousand items anyway. If you have a list that big, the editor will already be crawling even on some high-end computers.
5 Likes
I gotta agree with the argument that whatever lands in 2020.2 will stick around. I seriously doubt they will ever justify spending time deprecating this attribute and adding another one. Just imagine the confusion. This should be decided now and in my opinion non-reorderable lists don’t make any practical sense. If doesn’t break UI layout and doesn’t incur any tangible performance cost, go for the “enabled by default” approach and just be done with it.
5 Likes
Agreed.
So everyone who asks for this to be default: have you tried 2020.2 a13 [Reorderable] thing? Does it work well enough for that to be default?
I agree that it would be best to make decision on whether it’s opt-in (current alpha build) or opt-out (if needed) during 2020.2 cycle. Having it tested by lots of people would be a good thing for making that decision.
5 Likes
I tested it and think that it should be default. If you’re worried about performance even though it only starts to differ after a thousand items, micro-optimize and/or remove the animation.
3 Likes
It’s very usable the way you made it draggable. I don’t see any downsides to it
Just make sure there is a way to reset to default order and that the undo is working. ( still have to check if thats already the case )
A global preference would be my preferred way of opting out.
but I can see some people wanting more control.
The new faster enter playmode also has a global preference and in some cases I will turn it off but most of the time its on.
2 Likes
Have you thought about making it the default in (some) alpha versions? That way it’s forced on alpha testers and would cause drama if people are unhappy or silence if everything is fine. 
I’m not interested to add this attribute by hand to hundrets or thousands of fields to give it a real-world test and small scale tests have you done yourself already.
5 Likes
In case it is made default, then a “ReorderOption(bool reorderable)” (or NotReorderable, idk) tag would be great. It would allow one to turn on or off the reorderability of the array (in case one absolutely doesn’t want an array to be reorderable, you know… designers being designers, us progs sometimes have to be a little bit preventive…).
1 Like
Ok how about this:
- Flip the default behavior: arrays are reorderable by default (remove the [Reorderable] attribute that just went into this alpha).
- Instead have a way to opt-out, by adding a [NonReorderable] attribute that you can use. This goes back to pre-2020.2 UI control, basically.
Does that make sense?
21 Likes
Yes makes sense for me
1 Like