Struggling to find things in the new stdlib for 5.0... e.g. where is addingReportingOverflow implemented?


(Carl Peto) #1

I'm having trouble upgrading my stdlib interpretation. It seems like (as you would expect) quite a few things have changed since swift 4.2. I'm trying to keep my version up to speed but struggling a bit. For example, I can't figure out where the function body for addingReportingOverflow is for integers? I can see the definition in the FixedWidthInteger protocol and see it mentioned in the comments in the gyb file but can't find the body! Can anyone give pointers please?


(Manolo van Ee) #2

It's a bit difficult to find due to that the function name is generated by gyb. This should be it:


(Carl Peto) #3

Yes, that looks like it! Thank you!!

Is there any high level overview of the changes that have been made to stdlib in Swift 5.0? Or at least some discussion of the various significant design changes/structure that have been made in key areas? (i.e. Int, Pointer, Enum, etc.)


(Manolo van Ee) #4

Not that I know of (but that doesn't say much).


(Ben Rimmington) #5

(Ben Cohen) #6

This is a great list!

Just a word of warning about this one:

This is just a list of changes since we last re-baselined, which was done fairly frequently at the early stages of the checking tool because compiler changes can generate lots of churn. It isn't a full delta between 4.2 and 5.0.


(Ben Cohen) #7

I've been thinking that given how little gyb there is left at this point, it's time to go all in and degyb the remaining files. IntegerTypes changes so rarely that it's not a huge win to keep it gybbed. Alternatively we could do what is done elsewhere, which is keep the gybbed files, and have them be the thing you modify, but also check in the gyblets too, perhaps with a test that confirms the generated files match the gyb. This would probably help with attempts to make the std lib nicer to work on with Xcode or an LSP-enhanced editor.

This would make for a great starter bug for anyone interested.

edit: to clarify, I'm talking about degybbing the std lib code, not the tests quite yet – degybbing those would be a much bigger project and possibly should wait on more language features.


(Alejandro Alonso) #8

For more clarification for someone that decides to pick this up, how would you suggest degybbing IntegerTypes? Do you suggest splitting them into files like Int.swift, UInt.swift, etc.? Or shoving them all into a single file? (My personal preference would be to split into separate files.)


(Carl Peto) #9

I am very new to all of this but kinda love this idea. Aside from the obvious problems of code duplication. I'm actually doing exactly this in my micro stdlib. Currently still put everything in one file but separate files seems sense? But wondering what the core team think? It's still quite a big change isn't it?


(Alejandro Alonso) #10

Gyb begone:
Original PR: https://github.com/apple/swift/pull/21143
Part 1: https://github.com/apple/swift/pull/21149


(Dennis Vennink) #11

I don't think we should prematurely delete all .gyb files from the Standard Library.

Don't get me wrong, I don't like them either. They're cumbersome to work with and don't integrate into editor-based workflows.

But I think we should keep them for now. Working with them is uncommon and manually editing repetitive code has the potential for overlooked errors to creep in.


(Alejandro Alonso) #12

But isn't this the reason why we have tests?


(Dennis Vennink) #13

Sure, but then we're moving some of the complexity from gyb to tests. With gyb we can at least reason that if the tests pass for one generated arity or type there's a high likelyhood that they will also pass for other arities or types.

I'm not against the idea. But if we do go ahead with the deletion we need to put a system in place that ensures we're not hitting regressions or bugs.

My preference would be the following:

  1. Keep the .gyb files around.

  2. Generate the output manually.

    Note: it might be wise to add a comment at the top of all .gyb files that specifies its relative location with a disclaimer that the user is not supposed to edit the generated .swift file.

  3. Change the .swift.gyb extensions to .swift in CMakeLists.txt.

  4. Add tests that validate the output per @Ben_Cohen's suggestion.

    Note: for this to work we need to use gyb --line-directive "" in step 2.