You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
For example, a hypothetical macro could work as follows:
lettimecode= #timecode(.string("01:02:30:15"), at:.fps24)
// or even simplified to:
lettimecode= #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.
The text was updated successfully, but these errors were encountered:
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:
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.For example, a hypothetical macro could work as follows:
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
try!
with known-valid timecode literals.The text was updated successfully, but these errors were encountered: