Why string is sealed

Question

I am curious why System.String is sealed?

I know, I can do whatever I need to do not inheriting it, but still -- why?

There are a lot of classes that, by nature, are strings having specific methods and properties. Those are identifiers, emails, names etc.

Object oriented design suggests to encapsulate functionality in a specific class. And here we have weird situation that the most usable fundamental type in the most popular object framework is not extendable.

Thank you.

EDITED.

Comment regarding immutability. It is easy to hide all state-related things in private methods and allow child classes to have read-only access to class's data.

// Safe inheritable immutable string (pseudocode).
class String
{
   // Private state
   private byte[] state;
   private void EditState(byte[]) {}
   // Protected read-only access to state
   protected byte getReadOnlyData() {}
   // Available to child classes overridable methods.
   protected virtual getHashCode() {}
   protected virtual xxx() {}
}

In fact most of objects in real-world applications are strings. All those serials, ASINs, IMEI etc, as well as names, comments, are string by their nature. We get them as strings from databases, or they typed as string somewhere in text boxes on a web page or canned by barcode scanners etc.

And it would be really nice, more secure and much more elegant to have strings with specific features instead of inventing multiple classes, more or less doing the same.

Answer 1

There are a lot of classes that, by nature, are strings having specific methods and properties. Those are identifiers, emails, names etc.

This specific use-case would be better-handled by composition rather than inheritance, that is: "an email address has a string-representation" instead of "an email address is a string" (because an email address is really a composite of multiple sub-fields that just happen to have a succinct string representation when you're using SMTP).

Another point is that String is meant to be a fundamental type - it doesn't make sense to derive from an int - why a string? You would only need to derive from String if you want to extend System.String's implementation - for example, you want to override its GetHashcode implementation - but the number of operations you could conceivably want to override is very limited, so why should the framework maintainers bother with supporting that scenario?

As @Steve linked in the comments, this blog post by Eric Lippert also explains why many classes are sealed, especially from a maintenance PoV: https://blogs.msdn.microsoft.com/ericlippert/2004/01/22/why-are-so-many-of-the-framework-classes-sealed/

Finally, if you really want your own string behaviour (which is quite possible: you can length-prefixed strings, null-terminated strings, strings that exist as defined ranges in a larger string buffer, a linked-list based string, a Trie that holds multiple strings in a memory-efficient manner, a hybrid of multiple approaches, and so on) you can build your own implementation from scratch - none of these need to derive from System.String to exist. Sure, you wouldn't be able to pass it into a class that expects a String value, but that's only fair because perhaps those consumers depend on particular implementation behaviour of System.String (such as runtime performance, immutability, etc).

Answer 2

String is sealed mainly because it is immutable and CLR widely uses that feature (interning, cross-domain marshaling). If string would not be sealed then all CLR expectations on string immutability would not cost a dime.