Does that make sense? Swift is a type-flexible language, but it requires explicit type specification?:
CS193p Lecture 1 — My Own Summary
(There may be misunderstandings in my interpretation.)
The part related to the Title is the ‘some’ section below.
I first learned C as a hobby, reaching the level where I could create simple program using variables and conditional statements or controlling an Arduino. These programs were basic and only handled input and output via the command prompt. Because of this, the initial screen of an Xcode project felt very unfamiliar to me. Some parts were quite difficult at my level.
Behaves Like a…
Swift programming is said to focus on functions rather than data. As a result, Swift is designed in a way that minimizes concerns about dat types.
struct ContentView: View {…}
I understoood that the ContentView struct “behaves like a View”
In C, data types come first:
int dataName = …
Whereas in Swift,
var dataName: Int = …
This reflects Swift’s function-oriented approach, as opposed to C’s data-oriented approach.
Computed Property
In Swift, computed properties are defined like this:
var body: View {…}
The body variable returns a computed value inside the curly brackets, formatted as a View.
A simpler example:
var dataName: Double {return width * height}
In my mind, I interpret it as:
(C lang)double dataName = {width * height}
I’m not sure if this is entirely correct, though.
Some
Previously, we saw var body: View {…} as an example. But now, there’s a new keyword:
var body: some View {…}
I heard that the some keyword hides the return type. What does this mean exactly? I didn’t fully understand the explanation using LEGO as an example, so I did some further research.
Before diving in, one important thing to note is that Swift requires explicit type specification. However, View is not a type — it is a protocol. Since I don’t fully understand what a protocol is yet, I’ll just think of it as a kind of ‘rule’ for now.
Here another problem arises. Earlier, it was mentioned that Swift is a fuction-oriented language and that it infers types automatically. But now, it sounds contradictory to say that Swift requires explicit type specification.
The answer I found to this contradiction-although frustrating-is that Swift aims for both flexibility in handling types and type safety. Because of this, there are cases where type inference is allowed and cases where it is not.
Going back to the main point, the some keyword allows me to specify a return type in a way that limits its range without fully defining it. Normally, when defining body, we would need to explicitly specify one of the many types that conform to the View protocol. However, by using some(keyword) before View, I can abstract this and let Swift handle it dynamically.
Creating Instances of Structs
Image(systemName: “globe”)
Get Opunundo’s stories in your inbox
Join Medium for free to get updates from this writer.
Text(“Hello World!”)
These are ways to use Image and Text structs.
I understood that a struct is like a mold used to create products, and the newly declared Image and Text instances are individual products made using that mold.
Named Parameters
While looking at this:
Image(systemName: “globe”)
I noticed the part called systemName. This is known as a Named Parameter.
This concpet was hard to understand at first, so I thought of an analogy:
When ordering a MBP, if I just say, “Give me a MacBook”, the store clerk will ask many additional questions. And this will soon appear as an error or warning message in Xcode.
But, if I specify:
Order(model: “16-inch”, chip: “M4 Max”, SSD: “1TB”)
The order is clear, and you will get exactly what you want without confusion. Here, “model,” “chip”, and “SSD” are Named Parameters.
Parameter Defaults
If a default model is pre-set, you can order without specifying additional options and still receive a standard product.
@ViewBuilder
This allows multiple views to be combined and displayed together.
If I try to write multiple views like this:
var body: some View {Image(), Text()}
It will casue an error. To resolve this, Wrap the views in a Vstack to group them together:
var body: some View {Vstack{Image(), Text()}}
I imagined ths like a packing cube inside a suitcase. But I’m not sure if this is the best analogy.
View Modifier Scope
This determines where styles like font, size, and color are applied.
To apply a style to the entire screen:
var body: some View {
Vstack{Image(), Text()}.font(…) .color(…)
}
To apply a style only to the text:
var body: some View {Vstack{Image(),
Text().font(…) .color(…)
}}
By adding the modifier directly after Text(), it applies only to the text.
