> On Dec 29, 2015, at 11:40 AM, Amir Michail via swift-evolution > <swift-evolution@swift.org> wrote: >> On Dec 29, 2015, at 2:34 PM, Jacob Bandes-Storch <jtban...@gmail.com >> <mailto:jtban...@gmail.com>> wrote: >> >> I would not recommend phrasing these proposals as "Why doesn't Swift already >> support X?" when you are proposing a new feature. >> >> Instead, I'd like to see much more fleshed out examples of what you'd >> propose to change, and how it would help Swift developers. From the small >> amount of information you've given here, I can't understand what you're >> trying to do. > > Xcode is not open source and it is unlikely that Swift source to source > transformations that will be part of Xcode in the future (e.g., extract > method) will be open source. > > What I propose would be a way to embed source to source transformations into > Swift using directives in the language. As the language is open source, so > will be the transformations. > > Note also that the compiler already has the information required for source > to source transformations and so it makes sense to embed these > transformations in the compiler itself.
“Source to source transformation” is a really broad term and could mean anything from a macro system to defining an entirely new language that compiles down to Swift source. In this case, you seem to be asking for a refactoring engine that would be driven by source annotations, which sounds basically pointless except perhaps as a vehicle for extremely lazy research papers. I think a refactoring engine would be very welcome in the Swift repository. However, the technical design of its interface is a detail that should be decided according to the needs of its implementers and users rather than by random people making comments on mailing lists. If you are interested in contributing to that effort, that’s great, but you will need to write some code. Also, that discussion should occur on the development lists rather than the evolution list, since it’s fundamentally a question of tools implementation rather than language design. John. > >> >> Jacob >> >> On Tue, Dec 29, 2015 at 10:07 AM, Amir Michail via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> Source to source transformations are part of a developer’s job, don’t need a >> GUI, and can be done more easily and accurately by the Swift compiler. >> Moreover, the compiler could be made interactive taking in extra information >> from the developer as required during the "compile" (again without requiring >> a GUI). >> >> You could have special directives for source to source transformations such >> as: >> >> @extractMethodBegin >> … swift code ... >> @extractMethodEnd >> >> @indentBegin >> … swift code ... >> @indentEnd >> >> @commitCommentFragmentBegin >> … swift code ... >> @commitCommentFragmentEnd >> >> etc… >> >> Why encourage reinventing the wheel by pushing source to source >> transformations to tools of varying quality and completeness? >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
