Thank you for the clarifications. Now I see the scope is far more limited than I thought. But still it is a step in a direction that is very important to get right.
So, I echo Karl's question/concern:
2 Likes
I think that C++ is not comparable to Swift in this regard. There's massive survivorship bias in C++ regarding how much of constexpr you see because C++ libraries are simply not very good at doing anything that needs to interact with an operating system, and it turns out that when you don't interact with an operating system, almost everything looks pure.
When you start looking at the more integrated problems that Swift libraries attempt to solve, compile-time evaluation is applicable to a much smaller proportion of use cases. For instance, there's barely anything that can leverage compile-time evaluation in a UI component or in a networking library. I think that you're right that you can implement a CSV parser that is entirely available at compile-time, but I'm not really coming up with anything that would point to that being the best way to deal with a problem in the Swift ecosystem. If you have to consume csv input at build time, I think the way you'd go around in Swift is by creating a build tool that processes your CSV and generates something else. IMO, Swift's focus on library evolution and binary compatibility are good guards constexpr overreach.
Lastly, although it's true it creates function colors, the fundamental problem with async function colors is that old code (synchronous) can't call new code (asynchronous). This is the one direction that really matters because you can end up in a situation where you're stuck having to transition a ton of code to a new paradigm. The fact that new code (constexpr) can't call old code (not constexpr) is not nearly as much of a problem, because new code is effort that hasn't been spent yet.
2 Likes
The example given in the proposal is parsing a URL. I would argue that is even more complex than parsing a CSV file.
3 Likes
this is also true of swift, unfortunately. swift-system has been missing a lot of key APIs for a long time now, hence the emphasis on pure swift in the ecosystem.
2 Likes
In Swift 5.10 / Xcode 15.3 a _const attribute is available.
I get an error trying to do this:
func foo(_const _ val: Int) { ... }
_const let constVal: Int = 2
foo(constVal) // Error: Expect a compile-time constant literal
If understand the proposal correctly, this code should be valid.
@ArtemC Does this error appear due to unfinished implementation?
2 Likes
To circle back to bikeshedding again, yes something other than "const" please! Not just that C++ has tainted the word "const" with its many unexpected subtleties (and then also "constexpr" as previously mentioned), but let declarations are already described as being "constant":
Stored properties can be either variable stored properties (introduced by the
varkeyword) or constant stored properties (introduced by theletkeyword).
(https://docs.swift.org/swift-book/documentation/the-swift-programming-language/properties/#Stored-Properties)
Reading or having to write an attribute @const, especially using it like @const let, might sew uncertainly about what let means in the first place. The language should affirm its fundamentals, not counter or confuse them. If some keyword is needed to describe "something that is evaluated at compile time", it's keyword should allude to that concept, not some overload idea "constant".
And compile time types and functions are mentioned in the Future Directions section. A type described as "constant" would similarly overlap and breed confusion with the current concept of value type immutability. And a "constant function", does that even makes sense in anything but a xkcd 221 scenario?
4 Likes
Huge +1 here. The meanings should be clear and Swift have a chance to correct ambiguities of previous languages.
2 Likes