The Swift team has rejected three Swift proposals:

SE-0010 “Add StaticString.UnicodeScalarView would have added a way to index into a static string and return a static string. The team writes,

While the addition of StaticString.UnicodeScalarView is a useful feature by itself, the core team felt that it would be inconsistent just to add this narrow set of APIs for Unicode scalars. StaticString itself is a bit odd: it’s UTF-8 API works differently from String, there is no provision for UTF-16/32, etc. If StaticString is to gain Unicode support, it should be done comprehensively, not piecemeal. Moreover, with the aforementioned String re-evaluation underway, it is possible that StaticString itself might change considerably or even be obsoleted.

SE-0027 Expose code unit initializers on String asked to make public otherwise private functions that simplified the process of moving to and from byte representations. The team writes,

At this point, the core team feels that we have not fully explored the design space here, and that known alternatives (e.g., making the UTF-16 and UTF-32 views of a String mutable collections) might provide a better long-term solution. Moreover, the String type itself is undergoing a significant re-evaluation, so the core team feels that improvements to String should be delayed until the newer design is better understood.

SE-0024 Optional Value Setter ??= added a Ruby-like “assign only if nil” operator. The team writes,

While the ‘??=‘ operator’s semantics are clear and fit with other compound assignment operators, the use cases are not strong enough to motivate inclusion of this operator. Radek’s lukewarm +0.5 review captures the sentiment of the core team fairly well (as was echoed by others): one very common use case in the Ruby’s similar ||= operator is to assign a default value to an optional parameter or a local variable. However, neither case works well in Swift because ??= does not erase the optionality of the variable (and cannot be used to change a parameter now that var has been removed from parameters). Property access and subscripting could still benefit from ??=, but the latter case is likely to be handled better by a Dictionary subscript operator that can substitute a default value (see, e.g., Joe Groff’s suggestion).