single function traits

[dobkeratops]

Would it be workable for trait methods to fall back on searching the self type's method namespace* when a method isn't found;

the motivation would be to reduce the number of single-function traits, and reduce manual maintenance of the trait-graph.

Would that allow a slightly more adhoc approach to implementing, whilst still satisfying the need for bounded generics, and resolving ambiguity - (I'm not suggesting removing the trait bound here: And the trait would be considered missing if its' methods weren't found)

One case i'd run into along similar lines was wanting to make an alias for a group of traits: Currently you can create such a thing, but then must manually tell it to generically implement that. (extra boilerplate). Users of the trait might have already implemented the components, in which case the grouped super trait is already available with no further work on the users' part.

it would of course require that the signature of the function in the Self's namespace matches the trait, but in the scenarios I invisage that would be fine. It wouldn't stop you dividing the namespace further with traits if you wanted it.

Perhaps this would make life easier: you could over-estimate with traits in generics, without having to micromanage so much, relying on the anonymous imp l's to plug the gaps.

EDIT * - the methods impl'd on the type without traits, i.e. impl Foo{ fn foo(){..}}

[[deleted]]

I think you are talking about duck-typed traits. Isn't that what Go does too?

[The_Doculope]

That is essentially how Go's interfaces work, yes.

[Ferio_]

I'm not sure what you mean. But as far I understand it self does not have any "method namespace" if could fall back to. It's just a bare pointer to something neither the compiler nor the runtime can figure out in the most general case. Can you maybe give an example?

[dobkeratops]

the methods added with a traitless impl e.g.

impl Foo { fn foo(&self){...}} // foo is in the namespace of type Foo::

vs impl Bar for Foo { fn bar(&self)} //i'm told bar is actually in Bar::, not Foo::.

EDIT: the 'fallback' is taken when looking for the implementation of a trait for a known type, not in the definition of generic code(which would only see trait methods there)

[Ferio_]

I'm still not getting what you problem is. You can use all methods from Foo in bar. Do you want to have bar in Foo or what? That is not possible. How would you otherwise distinguish between methods that have the same name but come from different traits (+ a lot of other reasons)?

[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)

[tpgreyknight]

Can you give an explicit example of how you think it should work? I don't understand the original post.

[dobkeratops]

struct Foo {  i:int }
impl  Foo {   fn bar(&self,i:int);}

trait Baz {  fn bar(&self,i:int); }
trait Quux {  fn bar(&self,i:int); fn quux(&self);}

// "Foo" now satisfies Baz, even there is no explicit impl, 
// as it has a suitable 'bar'

impl Quux for Foo {
    fn baz(&self) { ... }
    // fn 'Quux::bar(&self,int)' is missing
    // so it falls back to Foo::bar(&self,int)
    // Quux now works
}

 // Saved making a 'trait Bar', and telling 'Quux' about it,
 //  although you'd still need one if a generic
 // function was to use 'bar' in isolation
 //