Crystal: Time::Span constructor with Int32 for days, minutes, seconds

[jaredmoody]

I'm new to crystal so forgive me if I'm misunderstanding, but it seems to me the Time::Span constructor is not behaving correctly:

Time::Span.new(seconds: 1)
# => no overload matches 'Time::Span.new', seconds: Int32
#  Overloads are:
#  - Time::Span.new(days : Int, hours : Int, minutes : Int, seconds : Int, nanoseconds : Int = 0)
#  ...

Passing 1 for days, minutes, seconds, all give the same error, but for nanoseconds it works:

Time::Span.new(nanoseconds: 1)
# => 00:00:00.000000001 : Time::Span

It seems to me all of these _should_ work, but if not then it seems like nanoseconds is at least inconsistently accepting 1 as an Int where the other arguments are not.

Here's my crystal version info:

```

crystal -v
LLVM: 6.0.1
Default target: x86_64-apple-macosx

[unscatty]

It's because there is no an overload in which you can only pass a seconds argument. In your case you have to either pass mandatory hours, minutes and seconds arguments like this:

Time::Span.new hours: 0, minutes: 0, seconds: 1

or seconds and nanoseconds

Time::Span.new seconds: 1, nanoseconds: 0  # Note that for this overload `seconds` and `nanoseconds` have to be named arguments

Or even you can do

1.second

which reads much better.

Check the API reference for more details

[straight-shoota]

I think the API should have allow to omit any component, defaulting all to zero.

So you can do Time.new(minutes: 1, seconds: 30) without having to specify days: 0, hours: 0 or compose the value as 1.minute + 30.seconds.

[vladfaust]

Also https://github.com/crystal-lang/crystal/issues/7143

[jaredmoody]

Thanks for the explanation, I'll close this as it's not a bug.

However, the compiler error could certainly be more helpful. "No overload match" made me think a type was incorrect; a missing argument error would have led me to the answer.

[straight-shoota]

Not a bug, but I see it as a feature request.

[jmbarnardgh]

Newcomer here. Just trying to absorb. I looked at #8257. That appears to be done but not yet closed. If/when #8257 does close, would this issue be closed by virtue of #8257 being closed? Or is there any diff in the specifics of this issue vs. that one?

[straight-shoota]

Yes, that seems to resolve this issue. It also mentions that in the initial post.