SE-0258: Property Delegates

For reference, there's a brief discussion of why a PropertyDelegate protocol doesn't work in the proposal. I feel that trying address those fundamental issues (like dealing with mutability) within protocols isn't something we want to tackle generally: protocols are meant to have very specific API contracts that are ABI and can't be made "fuzzy" to deal with mutating vs. non mutating getter/setters and such.

Additionally, I think the trend for Swift has been moving away from using concrete protocols and toward more ad hoc protocols, because protocols aren't (and won't ever be, IMO) expressive enough for our syntactic tie-ins. String interpolation, dynamic callable, dynamic member lookup---all of these are using ad hoc protocols because we want more-general overloading than can be expressed by a protocol. Given how hamstrung we are by the unfortunate designs of, e.g., the ExpressibleByIntegerLiteral and ExpressibleByFloatingPointLiteral protocols now being baked into the ABI, I really wish we had an ad hoc protocol there instead, which allows more evolutionary improvements within the constraints of existing ABI.

FWIW, we're specifically keeping @_underscoredAndLowercaseNames for compiler-defined attributes. It's the @Uppercase names that are provided for general extensibility, which lines up with the dominant convent for type names. That seems like the right expressivity / future evolution compromise.

As I said in the pitch thread, I suspect this is one of those concerns that will fade away immediately once people start using the feature. It assumes that the name of the delegate type doesn't convey the meaning of the annotation, but that's not the case: @Atomic var means the variable will be atomic. You can command-click on the Atomic if you want to learn the details of how it's done. Heck, that's better than you get with lazy.

The custom attributes discussion is happening. I suppose one could argue that that discussion could result in the whole idea getting radically revamped, so we should serialize the proposal reviews, but the level of enthusiasm for the custom-attribute direction has been high enough that I doubt the approach would get radically revamped.