The ability to convert any object to a string is very useful for debugging and most languages support this. Even in C it's frequently useful to print %p to identify objects.

Serialization should require involve separate APIs.

Which is why C# (and apparently other .NET constituents) has the excellent, but separate DebuggerDisplay API [0]. IIRC it also makes it possible to define a private implementation to communicate to clients that this pseudo-serialization is not part of the public API (like ToString() implicitly would be).

[0] https://docs.microsoft.com/en-us/visualstudio/debugger/using...

It should be opt-in though. A compiler-flag for debug builds or similar.

Why so, what are the downsides? It's not like it introduces any meaningful overhead at all, and there are plenty of situations where it is useful even in production (eg for logging in catchall "can't happen" top level exception handlers). Adding yet another compiler flag seems like a worse solution to me.

What you lose is the ability to model objects based on the behaviours that they can perform.

I want to be able to design objects that have toString() and I want to be able to design objects that don't have toString().

The same goes for clone(), hash(), getPtr(), getEndian(), equals(), toBytes(), toJson(), encrypt(), delete(), isNumeric(), toXml(), serializationVersion() or compare().

I suppose you could define toString() to throw an error, but obviously that's a messy hack in place of having that control. I can definitely appreciate the logic for making nothing intrinsic, and I can also see an argument for making equals() the only method of Object. (i.e. everything should have an identity function, but nothing more.)

Now I'm wondering... are there languages which formalize "implement with a throw" into some kind of explicit refusal to implement a method? Obviously there are method-sharing approaches other than inheritance, but I've never heard of "you must implement this, or explicitly choose not to".

I'm not quite sure what you mean, but it's standard in python if you have a method in a class that must be subclassed and overridden you can have the default raise a NotImplementedError

I was thinking about a condition that's specifically for "inherited but not supported", but that's pretty close to what I had in mind, yes.

Java doesn't have a language-level exception that's specifically for unusable methods, which can be a bit awkward. UnsupportedOperationException is the recommended answer, but it's relatively nonspecific as to why your operation wasn't supported. Apache's Commons extends that with NotImplementedException for cases where the call isn't definitionally impossible (e.g. adding to an unmodifiable map), but no implementation exists.

That %p approach sounds perfect.

If they wanted to make it worse, they could make it so you could call %s on any object, and if it wasn't defined, it would "conveniently" fall back to %p instead.

Then someone could could write an article called "Never Use %s for Behaviour"

Hah, such hate.

Lemme quote Goetz & Steele:

"Standard methods like toString and equals should not be forced on value classes, but should be customizable." (http://cr.openjdk.java.net/~jrose/values/values-0.html)

Great advice to be unemployable.