Support for Swift Macros

[orchetect]

Brief

Swift Macros can bring some novel and useful functionality.

Since macros can run code at compile time, it's possible to use them to create non-throwing Timecode constructors when:

• using timecode string literals or using component value literals, and
• using frame rate literal

This would allow for timecode validation checking at compile-time for timecode literals as described above.

Proposal

Take for example, a basic Timecode initializer that takes a String. Currently, this is throwing and requires the try keyword since at compile-time it is unknown whether the timecode string is a valid timecode at the given frame rate or not.

let timecode = try Timecode(.string("01:02:30:15"), at: .fps24)

For example, a hypothetical macro could work as follows:

let timecode = #timecode(.string("01:02:30:15"), at: .fps24)
// or even simplified to:
let timecode = #timecode("01:02:30:15", at: .fps24)

This macro could be evaluated at compile-time and be determined to be valid timecode, removing the requirement to use the try keyword. If the string is invalid timecode, a compiler error would be produced.

Benefits

• This would allow for less friction when using timecode literals, and would provide a safer alternative to the temptation to use try! with known-valid timecode literals.

[hiSandog]

The macro should share the same parser/validation rules as the runtime initializer so valid literals cannot diverge between compile time and runtime as formats evolve. Diagnostics could point at the exact invalid component and include the supplied frame rate, especially for drop-frame edge cases. Tests should cover string and component forms, rational frame rates such as 30000/1001, invalid frame numbers, and expansion output that remains usable without importing macro implementation details.