Disambiguate the meaning of `one`

[TotalVerb]

It seems that this is incorrect:

julia> one(Dates.Second)
1 second

The documentation of one says "Get the multiplicative identity element for the type of x". So the correct return would be Int64(1), since then one(Dates.Second) * Dates.Second(5) == Dates.Second(5) as expected. The current behaviour results in a MethodError which is not desirable.

If I did not miss something obvious, I could make a pull request.

[toivoh]

Agreed, the multiplicative identity must always be unitless.

[omus]

I believe this change would break empty StepRanges with Periods. Potentially this demonstrates a bug with handling empty StepRanges.

julia> Dates.Hour(5):Dates.Hour(1)
5 hours:1 hour:4 hours

The last step of the range is calculated via start - one(stop-start)

[nalimilan]

I guess one(stop-start) should be replaced with oftype(start, stop-start).

[StefanKarpinski]

The trouble is that there are (at least) two meanings of one that happen coincide in the absence of units: the multiplicative identity and the additive group generator (of the integers). I suspect that we need to distinguish these with different names and use the right one in each situation in order for our generic code to support units correctly.

[stevengj]

See also Keno/SIUnits.jl#18

[stevengj]

Maybe oneunit(x::T) for the additive group generator?

[stevengj]

Also, step(::UnitRange) = 1 looks wrong for the same reason.

[timholy]

This goes well beyond dates, so I'm adding a "decision" label here. I'm as guilty as anyone of being inconsistent about my use of one: when working on packages related to mathematics with units, then one(x) = 1 seems like the no-brainer fallback for almost anything. Whereas when I'm working on how to pick contrast defaults for displaying images, I want one to work for grayscale and possibly colors and return something with the same "units" as the color object. I agree with the desirability of separating these two notions of one.

With respect to StepRange, note that #17611 may fix this.

[andyferris]

This is actually really interesting - which is worse, a method error on one(T) or not having one(T)::T?

I imagine it would be bad if we had zero(Complex{Float64}) = 0, or even zeros(Float64, 10)::Vector{Int}, just because they are valid additive identities.

I almost think of zero(T) and one(T) as constructors for T, but maybe the syntax T(zero) and T(one) would be more natural for that in some respects.