[swift-evolution] [Planning][Request] "constexpr" for Swift 5

[Christopher Kornher]

I assume that the planned “hygienic macro” facility, if it has access to metadata, or “annotations", could be used for these sorts of meta tasks, .

This is slightly off-topic, but I hope that there is a way for macros to be fully expanded and debuggable (and even formatted). I use Cog with Swift as a kind of "macro-system on steroids” that provides these features. I would love to see a Cog-like system included as a standard feature of the language in the future. It could be a component of annotations, macros, or both.

I would like to see a source code generation pre-pass added for annotations, and hopefully macros when they arrive, so that developers can see, debug, and code against the expanded code. I realize that may be difficult or even impossible for some macros.

GOG uses Python as its macro language, which is certainly compatible with Apple’s toolchain. Using a real programming language for annotations, is extremely powerful.

The danger of adding a macro system too early, is that it can be used as a “cheat” to implement functionality that should be part of the base language and discourage language development. I trust that the core team will not let this happen.

See Cog: 
https://nedbatchelder.com/code/cog/ <https://nedbatchelder.com/code/cog/>

A fully integrated Cog-like facility this should have language support to cleanup the (pretty ugly) delimiters and eventually tool support to selectively toggle expansion, as we can today with code blocks, for example, in many tools.

I don’t mean to derail this discussion, but it seems that an annotation or macro system would be appropriate for this kind of feature.

- Chris


> On Jul 30, 2017, at 11:03 AM, Gor Gyolchanyan via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Tino Heth:
> If you read my reply to Daniel Vollmer, you’ll find that we’re thinking about the exact same thing. Your code snippers show my vision of compiletime beautifully 🙂.
> Now what I really want at this point is to here the opinions of the core team on this topic.
> 
> Swift Core Team:
> Have you guys thought of this? Do you think this is a good idea to put on the table or do you have different plans?
> 
>> On Jul 30, 2017, at 7:56 PM, Tino Heth <2th at gmx.de <mailto:2th at gmx.de>> wrote:
>> 
>> 
>>> more elaborate compile-time facilities, which would also provide extremely powerful meta programming features
>> That's an interesting twist — but whenever you put a "meta" somewhere, things tend to get complicated, and people end up with different associations to the topic… ;-)
>> I took a brief look at the C++ document, but it seemed still to much macro-like to me.
>> 
>> My take on the topic would be he ability to express common programming tasks (declaring a class, overriding a method…) in the language itself.
>> Imagine
>> public class ProxyViewController: UIView {}
>> Could be written as
>> let subclass = createClass(classname: "ProxyViewController", superclass: UIViewController, accessLevel: .public)
>> 
>> Quite stupid at first sight, and basically the exact opposite of syntactic sugar ("syntactic salt" already has a meaning… so I'd call it "syntactic pepper" ;-).
>> But now imagine that:
>> 
>> for (method, implementation) in UIViewController.methods where method.accessLevel == .open {
>>     subclass.methods[method] = { parameters in
>>         print("Subclass method \(method) called with \(parameters)")
>>         return implementation(parameters)
>>     }
>> }
>> 
>> 
>> Not that stupid anymore, isn't it?
>> I think this would be way cooler than poking around with variants of search & replace…
>> 
>> - Tino
>> 
>> (to get syntax colouring, I wrote ~30 lines of Swift that turn the straw man example into valid code… it's fun, maybe I play with it a little bit more ;-)
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170730/27f17abc/attachment.html>