{"action":"created","issue":{"url":"https://api.github.com/repos/rust-num/num/issues/126","labels_url":"https://api.github.com/repos/rust-num/num/issues/126/labels{/name}","comments_url":"https://api.github.com/repos/rust-num/num/issues/126/comments","events_url":"https://api.github.com/repos/rust-num/num/issues/126/events","html_url":"https://github.com/rust-num/num/issues/126","id":113029278,"number":126,"title":"Summing Vec<Complex<T>>: difference between core::num::Zero and num::traits::Zero","user":{"login":"SuperFluffy","id":701177,"avatar_url":"https://avatars.githubusercontent.com/u/701177?v=3","gravatar_id":"","url":"https://api.github.com/users/SuperFluffy","html_url":"https://github.com/SuperFluffy","followers_url":"https://api.github.com/users/SuperFluffy/followers","following_url":"https://api.github.com/users/SuperFluffy/following{/other_user}","gists_url":"https://api.github.com/users/SuperFluffy/gists{/gist_id}","starred_url":"https://api.github.com/users/SuperFluffy/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/SuperFluffy/subscriptions","organizations_url":"https://api.github.com/users/SuperFluffy/orgs","repos_url":"https://api.github.com/users/SuperFluffy/repos","events_url":"https://api.github.com/users/SuperFluffy/events{/privacy}","received_events_url":"https://api.github.com/users/SuperFluffy/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":5,"created_at":"2015-10-23T14:20:13Z","updated_at":"2016-01-03T23:52:00Z","closed_at":null,"body":"I wanted to sum a `Vec<Complex<T>>` using `std::iter::Iterator::sum()`, which has the signature:\r\n\r\n````rust\r\nfn sum<S = Self::Item>(self) -> S where S: Add<Self::Item, Output=S> + Zero { ... }\r\n````\r\n\r\nIt turns out that the trait `core::num::Zero` referred to in the signature is different from `num::traits::Zero` defined in `rust-num`. You get an error like:\r\n\r\n````rust\r\nerror: the trait `core::num::Zero` is not implemented for the type `num::complex::Complex<f64>` [E0277]\r\n````\r\n\r\nI think it is quite unfortunate that these two traits are not the same. They should be.\r\n\r\nA MWE to show the error would be:\r\n\r\n````rust\r\nuse num::complex::Complex;\r\nuse num::traits::Zero;\r\n\r\nfn main () {\r\n    let cvec = vec![Complex::<f64>::new(1.0,1.0); 10];\r\n    let s = cvec.iter().sum();\r\n}\r\n````"},"comment":{"url":"https://api.github.com/repos/rust-num/num/issues/comments/168556127","html_url":"https://github.com/rust-num/num/issues/126#issuecomment-168556127","issue_url":"https://api.github.com/repos/rust-num/num/issues/126","id":168556127,"user":{"login":"cuviper","id":36186,"avatar_url":"https://avatars.githubusercontent.com/u/36186?v=3","gravatar_id":"","url":"https://api.github.com/users/cuviper","html_url":"https://github.com/cuviper","followers_url":"https://api.github.com/users/cuviper/followers","following_url":"https://api.github.com/users/cuviper/following{/other_user}","gists_url":"https://api.github.com/users/cuviper/gists{/gist_id}","starred_url":"https://api.github.com/users/cuviper/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/cuviper/subscriptions","organizations_url":"https://api.github.com/users/cuviper/orgs","repos_url":"https://api.github.com/users/cuviper/repos","events_url":"https://api.github.com/users/cuviper/events{/privacy}","received_events_url":"https://api.github.com/users/cuviper/received_events","type":"User","site_admin":false},"created_at":"2016-01-03T23:52:00Z","updated_at":"2016-01-03T23:52:00Z","body":"We would provide them through our own trait, say `NumIterator`, which we'd implement for any `Iterator`.  If someone writes `use num::NumIterator;` they can call any method therein.  These specific methods would have the `Zero`/`One`/`Add`/`Mul` constraints as needed, just like the unstable `sum` and `product` do now.  I haven't tried, but I think there will be call ambiguity unless we name ours differently -- maybe `summ` and `prod`?  Or `num_sum` and `num_product`?\r\n\r\nAs for stabilization -- `num` is still compatible with Rust 1.0, and I consider it a breaking change to raise that minimum.  If those `std` versions do become stable, then eventually we may move up to whatever version that is, and then the equivalent `num` traits can go away or just be `pub use std...`, reexported.  Until that day, since there's no way to `cfg` rust versions, the `num` traits will just have to exist in parallel."}}