Skip to content

Commit bd5f6ed

Browse files
committed
Release post-16
1 parent 8ab3073 commit bd5f6ed

File tree

4 files changed

+119
-9
lines changed

4 files changed

+119
-9
lines changed

content/en/posts/post-15/index.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -3,7 +3,7 @@ date: 2024-09-23
33
title: Demystifying Modern macOS Development
44
slug: demystifying-modern-macos-development
55
images: [""]
6-
description:
6+
description: Learn the subtle differences between native Mac apps, Mac Catalyst apps, and Mac (Designed for iPad) apps.
77
topics: [macOS, SwiftUI, Catalyst, Swift]
88
---
99

content/en/posts/post-16/index.md

Lines changed: 68 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,68 @@
1+
---
2+
date: 2024-09-24
3+
title: Swift 6's New @retroactive Attribute
4+
slug: swift-6-retroactive-attribute
5+
images: [""]
6+
description: Learn about retroactive protocol conformance, and why you probably shouldn't use it on external types.
7+
topics: [Swift]
8+
---
9+
10+
# Swift 6's New `@retroactive` Attribute
11+
12+
Swift 6.0 introduced the `@retroactive` attribute to address a specific issue with protocol conformances. Here's what you need to know:
13+
14+
## The Problem
15+
16+
Suppose you are using a type from an external library and realize that the type does not conform to a protocol such as `Codable`. You might be tempted to add your own conformance.
17+
18+
```swift
19+
import ExternalLibrary
20+
extension ExternalType: Codable {
21+
// implementation here
22+
}
23+
```
24+
25+
However, doing this can be quite problematic. What happens if the library owner later adds their own conformance? Which code will execute? Your conformance or their conformance? The answer is that the behavior will be undefined at runtime, since we don't know which conformance will "win". Even worse, this same problem will propagate to every library that imports your library.[^1]
26+
27+
[^1]: There are a few exceptions to the this which you can find [here](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0364-retroactive-conformance-warning.md#detailed-design) and [here](https://forums.swift.org/t/amendment-se-0364-allow-same-package-conformances/71877).
28+
29+
## The Solution: `@retroactive`
30+
31+
To combat this problem, Swift 6.0 now emits a warning any time you retroactively add a conformance to an external type. However, there are some scenarios where it might be best to extend external types, despite this risk.
32+
33+
So, the `@retroactive` attribute allows you to explicitly declare that you are intentionally adding a conformance that might conflict with future updates to the original module.
34+
35+
## When to Use It
36+
**⚠️ You probably shouldn't use `@retroactive`.**
37+
Consider it a code smell.
38+
39+
If you **must** use it, then be sure to check every time you update your dependency to a new version. If they have added the conformance themselves, then this will create a conflict.
40+
41+
If you use `@retroactive`, you are, in fact, explicitly declaring that you acknowledge the risk and are willing to take responsibility for potential future conflicts.
42+
43+
## How to Use It
44+
45+
```swift
46+
extension ExternalType: @retroactive ExternalProtocol {
47+
// Implementation here
48+
}
49+
```
50+
51+
52+
## Alternative (for pre-Swift 6)
53+
54+
If you need to support older Swift language modes, you can silence the warning by fully qualifying the types:
55+
56+
```swift
57+
extension Module.ExternalType: OtherModule.ExternalProtocol {
58+
// Implementation here
59+
}
60+
```
61+
62+
## Conclusion
63+
Remember, while `@retroactive` provides a solution, it's best to avoid adding conformances to external types and protocols whenever possible to maintain better compatibility and reduce potential conflicts.
64+
65+
66+
## Recommended Reading
67+
- Read the full Swift Evolution proposal for more [info](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0364-retroactive-conformance-warning.md).
68+
- [Extensions in Swift: How and when to use them - SwiftLee](https://www.avanderlee.com/swift/extensions/)
Lines changed: 50 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,50 @@
1+
---
2+
draft: true
3+
date: 2024-09-17
4+
title: Exploring AI Powered Swift Development in Cursor IDE
5+
slug: exploring-ai-powered-swift-dev-in-cursor
6+
description: Is Cursor IDE's Copilot a good fit for Swift development?
7+
topics: ["Cursor IDE", "Swift"]
8+
---
9+
10+
# Exploring AI Powered Swift Development in Cursor IDE
11+
12+
13+
## Myths About Swift Development
14+
- You can only develop Swift in Xcode
15+
- Swift in VS Code is bad/doesn't work
16+
17+
### Actual Limitations
18+
- Only Xcode has the iOS SDK.
19+
20+
## Why Use AI to Develop
21+
- Ask questions about your code
22+
- Write code faster
23+
24+
## Reasons to consider using Cursor
25+
- Run AI off your device (unlike Xcode 16)
26+
- The LLM has project wide context:
27+
- `.cursorrules` file allows you to give project specific prompting
28+
- Type `@` symbol to add documentation to your prompts
29+
- Cursor Composer: Multi-file editing.
30+
31+
## About Cursor
32+
- Cursor is a fork of VS Code.
33+
- Cursor makes it ridiculously easy to switch from VS Code:
34+
- It ports all your settings, keyboard shortcuts, and plugins.
35+
36+
## Setup
37+
The setup for Cursor is basically identical to VS Code but with a few recommended extra steps.
38+
39+
### Install the Swift Extension
40+
Install the Swift Extension if you haven't done so already.
41+
42+
### Index the Documentation in Cursor
43+
44+
45+
### Add .cursorrules
46+
Each project in Cursor can optionally have a `.cursorrules` file. This is a file where you can put plain English instructions[^1]
47+
48+
[^1]: You can of course use other languages to provide prompts to the LLMs. In fact, that could be very helpful for your particular use case. However, the vast majority of the relevant text that these LLMs have been trained on is in English. In other words, you are likely to get better results if your prompts are in English. But fret not, even if English isn't your main language, LLMs are also very good at translation. Try prompts in your language first, and if the performance is sub-par, try translating your prompts into English to see if you get better results.
49+
50+
## Conclusion: What is The Future of Software Engineering?

content/en/unlisted/testing in TCA/index.md

Lines changed: 0 additions & 8 deletions
This file was deleted.

0 commit comments

Comments
 (0)