Add missing keywords for Swift

[AvdLee]

Information

• Language: Swift
• Plugins: 'none'

Description
Some of Swift's keywords are missing. This issue is here for myself to make a collection over the upcoming week, after which I'm happy to implement this myself. If you're reading this, feel free to open up a PR adding support for these keywords!

• associatedtype
• @autoclosure
• @discardableResult
• @dynamicMemberLookup
• fileprivate
• @resultBuilder
• @unknown

Also, not sure if this code is currently highlighted wrong as well:

Available

Current:

Expected:

[RunDevelopment]

I'm happy to implement this myself.

Thank you very much!

Also, not sure if this code is currently highlighted wrong as well:

What does #available mean? Is # part of the function(?) name? I search for this but could only find stuff related to parameters.

[AvdLee]

What does #available mean? Is # part of the function(?) name? I search for this but could only find stuff related to parameters.

It's an availability API to make the compiler happy when using latest API's while also supporting older iOS/macOS versions.

It has the same syntax of functions, which I guess is the reason for its current highlighting.

In Swift, it's called a declaration attribute: https://docs.swift.org/swift-book/ReferenceManual/Attributes.html

[RunDevelopment]

But attributes start with an @. This post explains the difference. Maybe we should highlight @available and #available differently?

Also, attributes seem to be very generic in Swift (devs can even define their own). It might be better to have a generic attribute pattern (e.g. /@\w+/) instead of the fixed list we currently have.

[AvdLee]

Also, attributes seem to be very generic in Swift (devs can even define their own). It might be better to have a generic attribute pattern (e.g. /@\w+/) instead of the fixed list we currently have.

That's actually a good point you raise. Property wrappers, for example, can lead to all kinds of @ statements. Though, the highlighting in that linked article about property wrappers does match what I see in Xcode:

It's hard for me to give a call on using a generic attribute in such that I don't know if it adds more than it breaks? If it even breaks anything, not sure either!

[RunDevelopment]

My guess is that XCode knows that SampleFile is a struct and therefore highlights it as such.

We could do the same thing. Using the class-name detection from #3022, we could split attributes in two. All attributes starting with an upper-case letter are assumed to be property wrappers and will be highlighted as @ + class-name. All other attributes will be highlighted like the keyword-like attributes we have now (e.g. @propertyWrapper).

If it even breaks anything, not sure either!

Prism's languages are an implementation detail. We can change whatever we want (hopefully for the better).

[AvdLee]

Prism's languages are an implementation detail. We can change whatever we want (hopefully for the better).

That makes sense!

We could do the same thing. Using the class-name detection from #3022, we could split attributes in two. All attributes starting with an upper-case letter are assumed to be property wrappers and will be highlighted as @ + class-name. All other attributes will be highlighted like the keyword-like attributes we have now (e.g. @propertyWrapper).

That should do the trick, indeed. There are a few exceptions though, like @IBDesignable, @IBAction, @MainActor. Quite a few of the ones that are currently defined within Prism. Wouldn't we end up highlighting those as @ + class-name as well, effectively making a mistake?

[RunDevelopment]

Hmmm, that's a problem. Would it even be possible to distinguish property wrappers from other attributes without compiling the program?

In that case, it might be best to be consistent to highlight all attributes in the same way. That's also what GitHub's highlighter does.

@propertyWrapper
@escaping
@MainActor
@SampleFile

[AvdLee]

In that case, it might be best to be consistent to highlight all attributes in the same way. That's also what GitHub's highlighter does.

That makes the most sense to me too, indeed!

[RunDevelopment]

I think #3022 resolved all the tasks in this issue. Can we close this now @AvdLee?

[AvdLee]

In that case, it might be best to be consistent to highlight all attributes in the same way. That's also what GitHub's highlighter does.

Does #3022 also include this? I did not see a new commit since our discussion here. If so, yes! Otherwise, the PR should include an update for highlighting those keywords.

[RunDevelopment]

Does #3022 also include this?

It does. I pushed the commit adding GitHub-like attribute highlighting before we talked about attributes here.

[AvdLee]

Perfect, thanks a lot @RunDevelopment. I'll make sure to test it out thoroughly on my blog and keep seeking for improvements over time 💪