Should Swift be closed to adding any new keywords, beside those that start with “#”? Or is it just not using a keyword for static-sized arrays? If yes for that last question, are you proposing that nominal arrays be dropped, since “array” is still needed as a tag to introduce them?
Still need some sort of special support. There either needs to be a directive inside the struct to create a contiguous block of objects, or your static-sized array generic struct needs to be a straight-up magical type. When I first had a similar idea, I had to consider how a directive would interact with other stored properties, or would I block said interactions. At that point, what’s the difference between a struct with a bunch of tweaks and a new category of type. We didn’t make enum a struct with funny settings, after all.
C++ has its set of punctuators fixed by the language. Swift doesn’t do this; its punctuators are mostly user level, just like identifiers. And just like identifiers, there are a small set of punctuators reserved for the language itself, an analogue of keywords. Using “x”, “*”, or “^” would take some string out of free use and into (conditional) reserved use. Since I’m already using “array” as a tag for nominal arrays, why not reuse the word for immediate arrays.
If this change like this is made, what about “[N for Int]” for immediate arrays and “[for Int]” for array-segment references? The count goes first so nested arrays keep their extent priority order the same as C’s nested arrays. (Otherwise, the C to Swift source-code converter would have to flip the order of the extents.) Using “of” for the separator would be better, but that would violate the desire to avoid new keywords. Of course, how would nominal arrays be declared under this design? Or would those be dropped?
— Daryle Walker Mac, Internet, and Video Game Junkie darylew AT mac DOT com |
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
