Can we finally get a built-in serializable dictionary?

I don't see any excuse now that generic serialization is supported. This also isn't something big that requires a lot of testing, pretty much the hardest part being the drawer.

 

And also, ReorderableList being a Attribute.

 

It seems in 2020.x every list is going to be reorderable, see roadmap at around 15min.

Spoiler

 

Wow. I mean years of pain later we get something actually useful. I'd love to not be critical but oft times Unity can be frankly daft in their decisions on what to prioritise.

 

It's absolutely mind boggling how long some improvements take. I mean we're talking about simple stuff (reordable list), something that seems to be done on a boring friday. Maybe there are just no boring Fridays at Unity Technologies

 

My guess is that it's probably a foundation thing. The way the editor is built restricts certain other things from being done easily. Or maybe performantly.

 

I don't know Dictionaries but Unity Team uses ReorderableList everywhere they want. I don't know what holds them up and after UI overhaul it is even more interesting.

 

ReorderableLists are not very good performance wise. I was recently setting up an input icon system for the new Input System. As I was setting up keyboard icons I got to about 40 entries where the editor became very slow, it got very difficult to get it all done. Thinking about it now a page system would ease that issue. After viewing the video, Unity is aiming to have the editor 100% UIElements so its probably not the same one we can use and should be much better performance wise. Some nice QoL in that video.

 

Odin does this, today, and has supported this for a while now. It definitely can be done.

 

Very cool stuff my guy, but not the point here.
Many programmers already know how manually serialize a dictionary, the problem isn't that part. The problem is the lack of a built in standard implementation that every team can rely on.

 

I think the point they were trying to deliver is that if a third party tool managed to implement it then Unity shouldn't have any restriction doing so too.

 

Unity's only limitation is time and the fact that every time a dev actually wants to address it they're moved to something that always has a higher priority. And there always is and will be something higher priority.

But Unity has to look at the fact that pain over time really does add up to be higher priority than they guessed. All the knock on effects of that too.

But stuff like reorderable list would not make Unity more money. I guess in the end the priority has to be if it makes them money or if it will affect most of their users. The problem is most of their users has a high churn while the people constantly working with Unity day by day, even asset store authors, are having a harder time than it ever makes sense for them to have.

Still, looks like Aras' new team and other initiatives are slowly turning things around and I'm happy for it.

 

Kind of curious about this what is the Aras team.

Also I do agree some minor features would get rid of some headaches and time spent on them. I think some of the minor features add up over time to create a much happier and easier development cycle.

 

Yo know what would be nice? To have a productBoard roadmap for all the quality of life improvements they have planned. @Aras @AskCarol @benoitd_unity is this something that could be done?

 

What shocked me the most about that roadmap was finding out Unity never implemented support for Windows' file monitoring APIs and re-scans the disk for changed assets every time it regains focus, which explains why it often freezes for several seconds when doing so. It's been over a decade since the editor was ported to Windows, geez!

 

People are allowed to moan as much as they like about specific features of Unity. All you have to do is go to the relevant sub forum and tag your post feedback then let fly.

 

@Aras' team is indeed doing a lot of useful things. QOL improvements are a lot more interesting than all the big features that's getting worked at, because it's something they're guaranteed to be useful, and will be useful a lot sooner.

I've said before that Unity's "solving hard problems" mantra often causes them to make bad decisions, because a lot of the problems we have are really easy to fix, as long as you have source access. But we don't, and even if we did, I doubt we'd want to maintain a Unity fork.

 

Hopefully it's not been a century, we won't be here to believe that become true
But yeah dictionary into json gonna save a lot... o_o...

 

Oh, and no attribute, please. This type of stuff should be default. Same goes for auto property serialization.

 

Hey, I've taken a look at the type definition, and it turns out that the built-in dictionary type is marked with `[Serializable]`, so the only reason why it's not serialized is because it has no data that can be serialized.
It also implements `ISerializable` and `IDeserializationCallback`, if that helps.

In any case, we could really use a serialization protocol API, something akin to Json.NET's `ContractResolver`, but for specific types. This would effectively allow property serialization, which would be necessary here for the `Keys` and `Values` properties. At that point, Unity should provide protocols for many more types.