Would "Hacks and workarounds" section in Wiki helpful?

[zpdDG4gta8XKpMCd]

There is a long list of requested features that may or may not ever be implemented. In the meanwhile developers need a way to go without them. There is quite a number of witty workarounds to missing features have been posted in separate issues. These workarounds get lost among other issues and sometimes closed which makes them hard to find. The developer's community might benefit from making a list of them and publish it at a well seen sight. A format of such list might be as follows:

Nominal types #202 (in investigation)

• How to make more better structural branded types #8510 (comment)
• Support some non-structural (nominal) type matching #202 (comment), Support some non-structural (nominal) type matching #202 (comment) together with 1.8: empty enums with same local name incorrectly considered same type #7267 (comment)

[mhegazy]

I would rather have a section about nominal vs. structural type systems in the handbook, along with recommendations for emulating nominal types as suggested in #8510, #202 and #4895.

[DanielRosenwasser]

I agree with @mhegazy, I'm not so sure I want to endorse "hacks and workarounds". Promoting certain patterns to achieve things is a sure-fire way to paint us into a corner when we assume no real world code would be impacted by certain changes.

[basarat]

Hacks and workarounds : https://basarat.gitbooks.io/typescript/content/docs/tips/main.html Indeed some from people like @Aleksey-Bykov himself with my personal opinions mixed in (hacks are fundamentally personal) 🌹

[RyanCavanaugh]

I'm reminded of the T|void "workaround" people were using to emulate non-nullable types and how badly that code works with real nullable types. We should be careful here and only list things that we consider to be OK code to begin with (i.e. things we consider to be plausibly correct uses of the type system).

[falsandtru]

I don't like hacks.