Drop stay named tuples content

Author: odersky

content/typeclasses-syntax.md

@@ -38,13 +38,6 @@ This SIP is part of an effort to get state-of-the art typeclasses and generic in
 These pain points are worth fixing on their own, independently of any other proposed improvements to typeclass support. What's more, the changes
 are time sensitive since they affect existing syntax that was introduced in 3.0, so it's better to make the change at a time when not that much code using the new syntax is written yet.
 
-
- 1. Named tuples are a convenient lightweight way to return multiple results from a function. But the absence of names obscures their meaning, and makes decomposition with _1, _2 ugly and hard to read. The existing alternative is to define a class instead. This does name fields, but is more heavy-weight, both in terms of notation and generated bytecode. Named tuples give the same convenience of definition as regular tuples at far better readability.
-
- 1. Named tuples are an almost ideal substrate on which to implement relational algebra and other database oriented operations. They are a good representation of database rows and allow the definition of generic operations such as projections and joins since they can draw on Scala 3’s existing generic machinery for tuples based on match types.
-
- 1. Named tuples make named pattern matching trivial to implement. The discussion on SIP 43 showed that without them it’s unclear how to implement named pattern matching at all.
-
 ## Proposed Solution
 
 ### 1. Naming Context Bounds