Can I avoid eager ambiguity resolution for trait implementations with generics? No. Is it possible to have [ambiguity resolution to be done at the call site, rather than at the definition site]? No. There’s a (long-delayed) RFC for specialization that will allow overlapping trait implementations, but only when one of them is more specific than … Read more
This problem can be reduced to the following simple example (thanks to turbulencetoo): trait Foo {} fn make_dyn<T: Foo + ?Sized>(arg: &T) -> &dyn Foo { arg } At first glance, it really looks like this should compile, as you observed: If T is Sized, the compiler knows statically what vtable it should use to … Read more
Note that the second argument to map is an implicit argument. There must be an implicit in scope with the appropriate types, or, otherwise, you must pass such an argument. In your example, That must be Set[String], B must be Int and Repr must be List[String]. Therefore, for that to compile you need the following … Read more
It may be helpful to think of the star projection as a way to represent not just any type, but some fixed type which you don’t know what is exactly. For example, the type MutableList<*> represents the list of something (you don’t know what exactly). So if you try to add something to this list, … Read more
Just use the non-generic registration overloads (the ones where you need to pass the 2 Type objects.) Then provide the open generic types of both your interface and the implementation: services.AddScoped(typeof(IGenericRepository<>), typeof(GenericRepository<>)); In your controller, add a dependency for a repository of a specific type (a closed generic type): public HomeController(IGenericRepository<Lookup1> repository) { … }
Overloading is typically the bugaboo of type-inferenced languages (at least when, like F#, the type system isn’t powerful enough to contain type-classes). There are a number of choices you have in F#: Use overloading on methods (members of a type), in which case overloading works much like as in other .Net languages (you can ad-hoc … Read more
The fact that &’a str does not implement Into<i32> is not taken into account, because there is no guarantee that it couldn’t be added later. This would then break your code. So if this were allowed the possible breakage would make it harder to add implementations to library traits. Unfortunately I couldn’t find documentation for … Read more
I must explain to the compiler that B is the same as A::Foo There is a special syntax for it: impl<A, B> Baz<A, B> where A: Generator<Foo = B>, { fn add_foo(&mut self) { self.vec.push(self.generator.generate()); } }
Rust 1.26 fn filter_one(input: &[u8]) -> impl Iterator<Item = &u8> { input.iter().filter(|&&x| x == 1) } fn main() { let nums = vec![1, 2, 3, 1, 2, 3]; let other: Vec<_> = filter_one(&nums).collect(); println!(“{:?}”, other); } Rust 1.0 fn filter_one<‘a>(input: &’a [u8]) -> Box<Iterator<Item = &’a u8> + ‘a> { Box::new(input.iter().filter(|&&x| x == 1)) } … Read more
This is doable in TypeScript 2.0+. By using an inline { new(): T } type to capture this, you’ll get what you wanted: type Constructor<T> = { new (): T } class BaseModel { static getAll<T>(this: Constructor<T>): T[] { return [] // dummy impl } /** * Example of static method with an argument: */ … Read more