These are chat archives for rust-lang/rust

26th
Mar 2018
Scott Cesar
@Kordalien
Mar 26 2018 00:25
Does anyone know why this:
impl<'a, N, M, L> Vec3<N>
    where (&'a N):Mul<f32, Output = M>, M : Add<Output = L>, L: Add<M>{
    pub fn dot(&self, other: Vec3<f32>) -> L::Output{
        return self.x * other.x +
            self.y * other.y +
            self.z * other.z;
    }
}
considers types M and L to be unconstrained?
Especially since this:
impl<N, M, L> Vec3<N>
    where N:Mul<Output = M>, M : Add<Output = L>, L: Add<M>{
    pub fn dot(self, other: Vec3<N>) -> L::Output{
        return self.x * other.x +
        self.y * other.y +
        self.z * other.z;
    }
}
does not?
Zakarum
@omni-viral
Mar 26 2018 06:03
@Kordalien types are unconstrained because compiler can't calculate them from types used in type for which implementation is declared
Here you only use N
And somehow it doesn't allow to derive M and L from bounds
Scott Cesar
@Kordalien
Mar 26 2018 06:05
the part thats confusing is that delcaring a constraint on &N fails, while declaring a cosntraint on N doesn't
I understand what unconstrained means
just not why it's unconstrained specifically in the case that &N is constrained instead of N
Zakarum
@omni-viral
Mar 26 2018 06:07
I guess the problem is 'a
It is not constrained
Try to use for<'a> &'a N: Mul...
If M doesn't really depends on 'a
Scott Cesar
@Kordalien
Mar 26 2018 06:11
that did the trick
impl<N, M, L> Vec3<N>
    where for<'a> &'a N:Mul<Output = M> , M : Add<Output = L>, L: Add<M>{
    pub fn dot(&self, other: &Vec3<N>) -> L::Output{
        return &self.x * &other.x +
        &self.y * &other.y +
        &self.z * &other.z;
    }
}
compiles
M shouldn't depend on 'a in a generic dot product
ultimately I would expect the underlying addition impl to have a clone behavior
if it's not being used with generic types
Zakarum
@omni-viral
Mar 26 2018 06:14
M shouldn't depend on 'a in a generic dot product
But it could in your first version
Scott Cesar
@Kordalien
Mar 26 2018 06:15
Thanks for poitning that out
I didn't even realize I was leaking that bound in the first implementation
Zakarum
@omni-viral
Mar 26 2018 06:15
No problem
Scott Cesar
@Kordalien
Mar 26 2018 06:17
Does one of the rustbooks document the full form of a where clause?
(Hadn't seen for<lifetime> in a where clause before)
Zakarum
@omni-viral
Mar 26 2018 06:20
I thought it is the most common place for for<'a> :smile:
Not sure for rustbooks though
Scott Cesar
@Kordalien
Mar 26 2018 06:22
I imagine it would be
I should say i hadn't seen for<'a> as a syntax at all
when I was looking through the rustbooks
Zakarum
@omni-viral
Mar 26 2018 06:23
It might be underdocumented being advanced feature
Scott Cesar
@Kordalien
Mar 26 2018 06:24
that could be
I've been moving a personal project from Scala to Rust so pushing on the type system happens faster than pushing on other design decisions I guess
Zakarum
@omni-viral
Mar 26 2018 06:26
Does type systems map well?
Scott Cesar
@Kordalien
Mar 26 2018 06:26
Pretty well
Rust has some niceties compared to Scala, Scala has some nicties compared to rust
Scala has their full fledged higher kinded types which Rust doesn't support currently (last I checked) but Rust makes it a lot easier to compute type level functions
(Associated types are much nicer than the implicit evidence and Kind projections Scala requires)
Zakarum
@omni-viral
Mar 26 2018 06:36
Yeah, associated types are like output for traits - type functions
Denis Lisov
@tanriol
Mar 26 2018 06:58
@Kordalien This syntax is called higher-rank trait bounds
Krisztián Szűcs
@kszucs
Mar 26 2018 09:20
Hey All! I’d like to ask for help. Trying to implement Arrow Layout with generic traits. This implementation works so far (currently only focusing on API, later the details), but struggling with a Struct type.
Restioson
@Restioson
Mar 26 2018 14:05
On a double ended iterator of size 10, will iter.nth(9) iterate from back?
Zakarum
@omni-viral
Mar 26 2018 14:06
It will yield last element
After that it will be exhausted
Restioson
@Restioson
Mar 26 2018 14:07
and for instance iter.nth(6)
?
I'm specifically thinking of LinkedList's Iter
Zakarum
@omni-viral
Mar 26 2018 14:07
nth(6) will move left end by 6 elements. For any iterator
Restioson
@Restioson
Mar 26 2018 14:08
(i'm using it because it has a predictable time [not growth, just it wont realloc and freeze the system])
damn.
it should really go from the back
Zakarum
@omni-viral
Mar 26 2018 14:10
No it shouldn't
next_back should
nth(N) is equivalent of calling next N times
It's implemented that way by default
Other implementations are alowed for better performance
Restioson
@Restioson
Mar 26 2018 14:11
then it should be implemented for linked lists
so it chooses front or back
Zakarum
@omni-viral
Mar 26 2018 14:11
It must exhibit same behaviour
So it has no observable differences apart of performance
Restioson
@Restioson
Mar 26 2018 14:12
Why?
It does
oh hm, nth is non consuming
Zakarum
@omni-viral
Mar 26 2018 14:13
next takes &mut self. So does nth
Why do you even need LinkedList?
If you want to iterate over it then using Vec can improve performance greatly
Even if you iterating with next
And if you iterate with nth then it is even more performance gain. Since vec::Iter implements nth with arithmetic
Restioson
@Restioson
Mar 26 2018 14:29
i need the time for push to be predictable
also i split and merge a lot
mainly because this is kernelspace so if it freezes the whole core freezes
Ingvar Stepanyan
@RReverser
Mar 26 2018 19:42
@Restioson Automatically choosing nth based on where it is in the list could be confusing, as it does mutate current iterator.
But if you just want to get nth element efficiently, nothing stops you from writing own helper function that uses either .iter().nth(...) or .iter().rev().nth(...) depending on what will be most efficient
Judson Lester
@nyarly
Mar 26 2018 20:03
From https://blog.golang.org/versioning-proposal: "Cargo allows partial code upgrades by giving up import uniqueness: a given import path can have different meanings in different parts of a large build."
I didn't think that was true.
Jiriki
@jirikivaari
Mar 26 2018 21:27
greetings
I'm new to rust and I'm considering doing some small program that'd be fun and useful perhaps for others
any recommendations?
Scott J Maddox
@scottjmaddox
Mar 26 2018 21:30
@nyarly I just threw together this test project, and it definitely works: https://github.com/scottjmaddox/rust-transitive-deps
Well... I say that, but now I realize I didn't actually make the dependency transitive... let me fix that and make sure it still works
Scott J Maddox
@scottjmaddox
Mar 26 2018 21:40
Okay, it still works.
Judson Lester
@nyarly
Mar 26 2018 22:51
That seems like an anti-pattern...
Maybe less so in Rust - my concern is when crate A returns a value from one function that its consumer passes into another.
If two versions of A are required by intermediate deps, and the ultimate consumer winds up ferrying values returned by A-n to a function in A-m, that seems bad.
But strong typing in Rust probably makes that moot.
Denis Lisov
@tanriol
Mar 26 2018 22:56
@nyarly There's a difference between public and private dependencies... for example, for log you never have these types in your APIs.
Judson Lester
@nyarly
Mar 26 2018 22:56
Does cargo treat them differently?
Denis Lisov
@tanriol
Mar 26 2018 22:57
Not yet, but there's an accepted RFC for this: rust-lang/rfcs#1977
Judson Lester
@nyarly
Mar 26 2018 22:58
Right on.