Hello! I'm new to the community and just beginning to explore how the compiler works and how new features are proposed. I've noticed that there are many places in the source code with FIXME comments. How and when are these comments usually addressed? I'm guessing that these comments are resolved through the standard pitch - proposal process?
3 Likes
If fixing it does not involve changing the developer-facing semantics of Swift there’s no need for a pitch, a PR is fine. If it’s an additive change then a pitch would be appropriate.
Note that many fixmes may end up being unfixable without breaking source compatibility, which ultimately means unfixable period.
3 Likes
Sounds like those code blocks should be marked with DON'T FIXME's instead 
10 Likes
Identifying which FIXMEs are no longer possible post-Swift-5 and changing them to "ideally we'd do X, but we probably can't because Y" sounds like a tedious but potentially helpful task.
11 Likes
I wrote up my view of how the Swift project uses the word “FIXME” a few years ago, when I was still on the project. I stand by it, though others have disagreed (usually with “maybe we should have an issue tracking each one, then people would be less cavalier about them”).
7 Likes
Understood, thank you for the thoughts everyone! I certainly agree with you @David_Smith, and I'd volunteer to try but I'm still working toward a better understanding of the language and all of its interconnected parts 
I'll return to the idea as soon as I feel more capable!
1 Like