[swift-dev] Advice for implementing "literal values as generic types"

David Sweeris davesweeris at mac.com
Wed Aug 30 03:43:51 CDT 2017


> On Aug 29, 2017, at 15:47, David Zarzycki <zarzycki at icloud.com> wrote:
> 
> Hi David,
> 
> To add to what I wrote earlier, the design of the Swift is such that adding new features isn’t “hard”, but it does require time and patience because most new features have ripple effects on other parts of the compiler that need to be thought through. Fortunately, the design of the compiler is such that vast majority of those ripple effects will cause a compile time failure. This is why I encouraged you to add new “.def” nodes up front. That’s the good news. The bad news is that you still need to think through the ripple effects and that means developing some minimal design and debugging expertise over the compiler as a whole. If you’re not discouraged by the process, the experience is quite rewarding.

Not from that, no. All the meta-programming stuff in the .def files (and the enums that reference them) is still hard for me to follow, but I'll figure it out, and it takes more than mere confusion to discourage me. :-)

Honestly, the relative difficultly of getting a working dev environment going is *way* worse than trying to figure out how to implement a feature...
Somewhere along the line today I synced my repo with Apple's to make sure nobody had refactored the type system or something while I wasn't looking, and unknown to me until a few minutes ago, the newest version requires Xcode beta 6 to build, which requires macOS 10.12.6. Well, I'm still on 10.12.5 because 10.12 doesn't support my 2008 Mac Pro at all (even though everything except the wifi works perfectly... in fact better than 10.11, at least for me), so updating the OS is a huge hassle... you've gotta jump through a bunch of hoops, else you'll end up with a boot volume which has incorrect (yet strongly held) views on whether your computer can boot off of it. Having stuff suddenly fail to compile after you've been mucking in files that you don't understand yet (*.def) -- even after saving copy of the files you were editing then telling Xcode to discard all changes -- is enough to make you think you somehow messed something up. Then you delete everything in the "sources" directory, and spend 3-4 hours or so starting over with an attempt at getting a clean install/build, only to notice halfway through that it's not going to work because now the compiler needs a newer version of Xcode (does it really, or does it only need the newer command line stuff?). 

Anyway, not knowing an easy way to tell if the problem is in your code or the dev environment, and not knowing how to fix the problem if it is in the environment (short of spending 3+ hours hoping that following the directions from the top will make everything happy) -- that can get discouraging.



> One more tip: if you’re going to add a new language feature, focus first on the type system and writing tests. Once you feel that implications are fully thought through, you can move on to “code gen” (i.e. SILGen and IRGen). If you rush to “code gen” first so that you can play with your shiny new feature, then you’re likely to get frustrated by self-inflicted bugs. You can experience the blissful pre-code-gen world by invoking swift like so: swift -frontend -typecheck file.swift

Sounds like good advice... I think I'll experiment with that tomorrow, after I figure out how I'm going to get beta 6 running.

- Dave Sweeris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20170830/3e2f9f15/attachment.html>


More information about the swift-dev mailing list