From bba7095f9b1cfa1438d6ee46e5370c7c99c0fa2b Mon Sep 17 00:00:00 2001
From: Runxi Yu <me@runxiyu.org>
Date: Fri, 26 Sep 2025 22:41:56 +0800
Subject: [PATCH] Don't use details/summary

Because Lindenii forge's goldmark forbids them and just drops them

---
 README.md | 47 ++++++++++++++++++++++-------------------------

diff --git a/README.md b/README.md
index 4597e056fa3d0fb69c72b1163648b4a6acfaa29d..277d3e87f3ab4f047f1ae094b783ab15275e91f7 100644
--- a/README.md
+++ b/README.md
@@ -52,31 +52,6 @@ > them to your specific use-case. Optimizing every other data structure that
 > your program makes use of, but which is not bottlenecking your performance,
 > is a premature optimization.
 
-<details>
-<summary>(My own dissenting opinion)</summary>
-<p>
-While the above is an explanation of why Hare does not have generics, it serves
-as a general argument against general-purpose data structures, such as those
-implemented in this library. For examples, when a key-value map is needed but
-is not a bottleneck, they may recommend using a simple slice of pairs and
-iterate through them linearly. We respectfully dissent, because we believe that
-general-purpose data structures can be implemented in a way that is efficient
-enough for many use cases, even if not as efficient as a hand-crafted data
-structure for each specific use case. It is, instead, a premature optimization
-to hand-craft maps for specific use case that would want something better than
-a linear search. Even though hashmaps and tree-based maps could be considered
-an optimization over a linear search, optimization should not be
-all-or-nothing; an appropriate amount of optimization such as using hashmaps in
-many places, is better than having linear searches everywhere where they are
-slow, and is also better than hand-crafting maps for every conceivable use case
-where linear searches are too slow. In practice,
-<a href="https://paste.sr.ht/~runxiyu/a0b49d84a3c9f3b35a05dd60993a3cd9d185bfff">many codebases</a>
-use numerous auxillary maps which share similar access patterns but may use
-differen types. Re-implementing a bespoke and non-general-purpose map for each
-key/value type is likely a waste of effort if access patterns are similar.
-</p>
-</details>
-
 As a consequence of not having generics, the data structures here are not type
 safe. Structures here typically use `[]u8` keys and `*opaque` values.
 
@@ -107,3 +82,25 @@ [`#chat`](https://webirc.runxiyu.org/kiwiirc/#chat)
 on
 [irc.runxiyu.org](https://irc.runxiyu.org/).
 
+## Quick dissent to the argument against generic data structures
+
+While the above is an explanation of why Hare does not have generics, it serves
+as a general argument against general-purpose data structures, such as those
+implemented in this library. For examples, when a key-value map is needed but
+is not a bottleneck, they may recommend using a simple slice of pairs and
+iterate through them linearly. We respectfully dissent, because we believe that
+general-purpose data structures can be implemented in a way that is efficient
+enough for many use cases, even if not as efficient as a hand-crafted data
+structure for each specific use case. It is, instead, a premature optimization
+to hand-craft maps for specific use case that would want something better than
+a linear search. Even though hashmaps and tree-based maps could be considered
+an optimization over a linear search, optimization should not be
+all-or-nothing; an appropriate amount of optimization such as using hashmaps in
+many places, is better than having linear searches everywhere where they are
+slow, and is also better than hand-crafting maps for every conceivable use case
+where linear searches are too slow. In practice,
+[many codebases](https://paste.sr.ht/~runxiyu/a0b49d84a3c9f3b35a05dd60993a3cd9d185bfff)
+use numerous auxillary maps which share similar access patterns but may use
+differen types. Re-implementing a bespoke and non-general-purpose map for each
+key/value type is likely a waste of effort if access patterns are similar.
+

-- 
2.48.1