Section 1/71 menit

1. Masalah yang Dipecahkan

1. Masalah yang Dipecahkan

Gap antara internal dan public

Sebelum Swift 6, Swift punya 5 access level: private, fileprivate, internal, public, open. Ada gap besar antara internal dan public yang sangat terasa ketika membangun SDK atau framework multi-modul.

Skenario: Library multi-modul dengan Swift Package Manager

swift
MySDK (Swift Package)
├── Core/          (Module A)
│   ├── Networking.swift
│   └── Authentication.swift
├── Analytics/     (Module B)  
│   └── Tracker.swift
└── UI/            (Module C)
    └── Components.swift

Masalah: Analytics butuh mengakses fungsi internal Core, tapi kamu tidak ingin fungsi itu accessible oleh pengguna SDK.

swift
// Core/Networking.swift
public func fetchData() { ... }     // terlalu public — user bisa pakai ini
internal func _internalHelper() { } // tidak bisa dipakai oleh Analytics!

// Analytics/Tracker.swift
// _internalHelper() tidak visible dari sini karena berbeda module
// Terpaksa jadikan public:
// public func _internalHelper() { }  // ❌ "public" tapi naming dengan _ = kebingungan

Dilema klasik:

  • Jadikan internal → tidak bisa dipakai module lain dalam paket yang sama
  • Jadikan public → accessible oleh SEMUA pengguna, termasuk end-user yang tidak seharusnya tahu
  • Solusi sebelumnya: naming convention _ prefix (tidak enforced compiler), @_spi (unofficial), atau modul monolith yang besar

Dengan package:

swift
// Core/Networking.swift
package func fetchData() { }  // visible ke semua module dalam satu Swift Package

// Analytics/Tracker.swift — module berbeda, PAKET YANG SAMA
import Core
fetchData()  // ✅ OK: package access level