> On Jun 12, 2016, at 6:05 AM, Alexander Momchilov > <[email protected]> wrote: > > Aren't macros totally different? > > Anyways, weren't macros rejected? I thought Swift was trying to avoid having > the hefty reliance of preprocessor macros that C did.
Sorry I was not referring to C-style macros (i.e. preproc). I was referring to a macro language in the sense of the scala compiler macros or other languages that let you insert compile time code inside your source (like D). I was of the opinion that it would be a short step to support something like embedded SIL inside string literals. But Chirs ruled out compile time code execution stressing that it should not be a replacement for designing a great language. Maybe around 4 or 5, when the language is mature, then compile time code execution (macros) can be added > >> On Jun 9, 2016, at 1:48 AM, L. Mihalkovic <[email protected] >> <mailto:[email protected]>> wrote: >> >> Chris has rules macros out-of-scope for 3.0. Who knows, maybe they'll be >> allowable in 4.0 >> >> On Jun 9, 2016, at 1:41 AM, Alexander Momchilov via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >>> Preface: I know this is likely a large undertaking to implement, but I >>> think it's worth it. >>> >>> In addition to the typical compiler optimization of constant math >>> expressions, some languages (such as D and C++) have support for running >>> arbitrary functions at compile time >>> <https://en.wikipedia.org/wiki/Compile_time_function_execution> (with some >>> constraints). >>> >>> I see many advantages of this: >>> On iOS/OS X: it could precompute the UI and app initialization logic >>> (wherever possible) to speed app load times >>> It can significantly speed up the initialization of applications with large >>> static properties. E.g. large constant Dictionaries could be precomputed. >>> You could keep complex math expressions (including custom functions) in >>> their unevaluated form, without the pressure to precompute them elsewhere >>> and hardcode in the result. >>> Dynamic programming: expensive look-up tables could be precomputed. These >>> wouldn't necessarily be large in size, but if their elements are especially >>> expensive to compute, there would be a huge advantage to precomputing them. >>> >>> What do you guys think? Can you think of any other useful applications? >>> Would it be worth the implementation effort? >>> >>> - Regards, >>> Alexander Momchilov >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
