Unary + and * promote numbers

[lindahua]

If + and * promote numbers, as follows, writing type stable codes would be more convenient:

+ (x::Number) = x + zero(x)
* (x::Number) = x * one(x)

Specialized methods can be provided so that we don't need to actually do the computation for common numeric types.

[JeffBezanson]

I rather think we should make x + x be the same type as x more often.

See issues #5806 #5413
Also my comment #6211 (comment)

[StefanKarpinski]

I agree that we want typeof(x+x) == typeof(x) more often. A good way to approach this might be to reason about what type we want [x] + [x] to produce and then extrapolate back to the scalar case from there. In particular, this is a little more nuanced than always having typeof(x+x) == typeof(x) in that you probably still want true + true == 2.

[JeffBezanson]

Yes, that's true --- I think we'd have to keep true + true == 2. Fortunately +true already gives 1.

Another possibility is providing a good interface for "promoting reduction", e.g. summing Float32s in double precision, or summing Int8s as Int64s, etc.

[StefanKarpinski]

sum(widen(eltype(v)), v)?

[johnmyleswhite]

Is there an open issue with the 0.4-projects tag that subsumes this issue? From some searching, I don't see one.

[pao]

Quickest way to find out is probably to add the milestone, then get yelled at if it was a bad idea.

[johnmyleswhite]

Good strategy.

Might be worth noting that there are bunch of open issues that touch on parts of this issue, but they don't seem to summarize the core issue very well. For example, there's a bunch of good points in #6211, but you wouldn't find it by searching the titles of issues.

[pao]

Is this a dup of #3759 (which now has a PR, #8028)?