Changes to Foundation must go through swift-evolution

Does it, though? This is exactly the thing that I would like some clarification about.

Just you thinking that corelibs-foundation belongs to Apple and they have some special right to change whatever they like illustrates the problem. (EDIT: Not just "Foundation". That's an overloaded term which can also refer to the Obj-C wrapper around CF, which of course is still an Apple-private project. We're talking about the Swift wrapper around CF).

In fact, historically, we have plenty of proposals which are / only / about / Foundation. Features like Codable started out as pure Foundation-only proposals until review feedback made a case for making it part of the standard library (I remember very well - I was one of the ones who argued that case!). I'm pretty sure I'm not just dreaming this.

Really, I chalk this up to a simple mistake/misunderstanding. The Foundation team were probably working on a lot of prototypes in parallel, and after working on this project in private for so long, they likely just 'forgot' that they can't just make changes to the public Swift API like they can for Obj-C. It happens; we're all only human and I don't think it's fair to point the finger at any individual. Lots of people saw my earlier attempts to raise the issue and said nothing, and I myself should have pressed the issue more.

As I said, I think we should clarify what the situation actually is, and if mistakes were made, we should endeavour to do better in future.

If the DataProtocol design had gone through a swift-evolution review, perhaps somebody would have noticed the similarity to _HasContiguousBytes, and like Codable, perhaps parts of it would have been lifted to the standard library. Maybe even DataProtocol itself (in lieu of an actual stdlib Data type -- I agree with you about how fundamental it is). The project is too big for any single person to know everything, and we benefit from having as many eyes as possible scrutinise the design.

8 Likes