Type conversions complexity

[machaval]

One of the things that I struggle the most is type conversions that are not trivial. This means that requires Parameters

For example converting a DateTime
toEpoch

now() as Number {unit: "seconds"}

Or toMillis

now() as Number {unit: "milliseconds"}

Or converting a Date to String

now() as String {format: "YYYY/MM/dd - hh:mm:ss"}

I think all this transformations are not that hard to understand what it does when you read it but are very hard to remember how to do it. It requires to now one this new syntax of how to pass arguments to the type conversion.

Questions

• Should we transform this into functions?
• Should we have one module called Conversions with all the type conversions? Or should we put each type conversion in the corresponding module

[afelisatti]

What examples do we have for similar functionality in other languages? Will users understand they require a "conversion" or would they prefer working with target/source types?

[menduz]

The closest I can think of is SQL (Transact SQL is very well documented in general terms)

• Documentation
• stackoverflow.com convert-date-format-into-dd-mmm-yyyy-format-in-sql-server

Other remotely similar approaches, I don't recall languages with formatting on the type system, the following are libraries:

• https://doc.rust-lang.org/std/fmt/
• https://github.com/fmtlib/fmt#examples

Those are have some common patterns. In uncommon cases conventions vary tho.

[jorgegarciamule]

We should not forget that the compiler knows that after Number you put an object with unit and other 3 attributes and that unit is expecting a value from a fixed list. All of this typing gives the IDE tools to assist the developer no need to remember everyhting.