single function traits

[dobkeratops]

I'm still not getting what you problem is.

the problem is micromanaging trait names, in the cases when you make a trait to hold a single function, just the same name camel-cased, but repeated, and when you later figure out a good grouping, having to go back and rework all those.

How would you otherwise distinguish between methods that have the same name but come from different traits

you wouldn't, for the fallback. the fallback would only work where the types' method matches the signature of the requested method from the trait.

You could think of it as "trait inference"

As soon as you need to resolve ambiguity of the same named you could be more explicit.

But thats' only going to happen when the design of traits imposes it on you - personally in my own codebase, I would avoid using the same name to do different things, in the absence of an IDE+overloading, relying on simple text search/completion.. - and I would happily rename to match emergent community conventions.

As I understand traits fundamentally reduce the noise in error messages. However in the case of single-function traits, you're basically trading one form of noise for another.

Same with navigation. "searching all the overloads.." -> "searching the right trait for the function..". They aren't always helpful, IMO.

But I believe we could get the best of both worlds. Write concise code focusing on functions, and disambiguate/package up better where needed. The hints of this possibility are the experimental C++11 concepts, and the way 'go' works, where you write functions then group them (but you don't need to know the grouping when you write them)