Swift part10 [無断転載禁止]©2ch.net

2017/02/20(月) 10:00:13.40

WWDC2014で発表されたAppleの新言語Swiftについて語りましょう

関連スレ

プログラミング言語Swift　Part4
http://potato.2ch.net/test/read.cgi/mac/1484763495/

[SDK]iPhoneアプリ開発初心者質問箱48[touch][iPad]
http://potato.2ch.net/test/read.cgi/mac/1484217623/

Xcode part14
http://potato.2ch.net/test/read.cgi/mac/1476190499/

Swiftアンチスレ part1
http://echo.2ch.net/test/read.cgi/tech/1458491343/

前スレ
Swift part9
http://echo.2ch.net/test/read.cgi/tech/1476758084/

VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured

2017/05/24(水) 07:14:18.79

このスレチの話題の結末が

MFCがmacOSで使える、そうSwiftならね

だったら感動する

2017/05/24(水) 10:39:54.11

感動はするけど、真っ平御免だなw

2017/05/24(水) 10:40:45.91

>>642
怖いもの見たさで再挑戦したいだけ。
スレチだし気にしないで。

2017/05/24(水) 10:44:09.55

>>642
動作の軽いアプリが作れる。
.netアプリは動作がモッサリ

**デフォルトの名無しさん** (JP 0H2f-CgLL) · 2017/05/24(水) 11:45:23.69

MFCはクラスライブラリとは言ってるけどただのモジュールだからなω

2017/05/24(水) 12:03:02.42

KFCはファーストフードとは言ってるけどただのフライドチキンだからなω

**デフォルトの名無しさん** (JP 0H2f-CgLL) · 2017/05/24(水) 12:10:44.50

KFC高いよね

2017/05/24(水) 12:40:42.62

あとポケトも不味いよね

2017/05/24(水) 12:43:35.78

macもファストフードって言ってるけどハンバーガーなんだよな...

2017/05/24(水) 15:21:05.18

もうkotlinでいいんじゃね。大体同じだし。

2017/05/24(水) 15:27:20.63

Kotlinの方が名前が可愛いな

2017/05/24(水) 15:39:03.23

バカッターの次はマスト鈍かよ
Swiftはコンパイル必要とかスクリプト言語だとかクッソデタラメばかり撒き散らしてやがる
Swiftはスクリプト言語のようにJIT実行もできるし事前コンパイルして動作することもできるっちゅーねん
よくわかってないからと言って既存のカテゴリに当てはめようとするからおかしくなるんだ。黙ってればいいのに。
twitterもマストドンもバカに絡まれたくないから間違ってても誰も訂正してくれないてことはもうそろそろ理解しないといけないだろうに

2017/05/24(水) 15:43:46.34

つまりkotlin統一でいいね？

2017/05/24(水) 16:16:47.79

kotlinのvar, valが嫌いだ。
var, letにしてくれ！

2017/05/24(水) 17:53:01.63

じゃあvar, letにした新言語Kotiftで

2017/05/24(水) 18:40:00.41

>>647
そうそう。
macで使えるようになって嬉しいとしたらDelphiのVCL。
C#の中の人(Delphiの生みの親)をMSから引き抜けw

2017/05/25(木) 08:20:49.95

>>658
VCLって使った事ない。
けど、噂には聞いている。

最近のDelphiではiOSアプリ作れるのか？

2017/05/25(木) 08:39:03.16

RAD StudioってのでiOSアプリ作れるみたい。

2017/05/25(木) 09:04:58.00

http://qiita.com/kazaiso/items/7f4955318f9d40a391fc

2017/05/25(木) 09:55:30.40

>>661
ブラクラ

**デフォルトの名無しさん** (JP 0Hcf-Evzo) · 2017/05/25(木) 10:26:57.11

ブラクラではないが特に読む意味もなかった

2017/05/25(木) 10:35:05.59

>>659
.netがVCLに似てる。
ネイティヴ版.netって感じだよ。
言語がC++かObjectPascalってだけで。

.netのForms使えるならVCLも違和感無く使える。

2017/05/25(木) 11:18:46.81

>>664
なるほど！VCL良いじゃん。

Common Language RuntimeとかいうInterpreter無しに.netモドキが動くなんて。

2017/05/25(木) 12:08:23.03

>>662
ブラクラとは、どういう意味ですか。

2017/05/25(木) 12:36:36.05

>>666
ブラクラとは、どういう意味ですか。とは、どういう意味ですか？

2017/05/25(木) 12:53:08.46

>>667
お前、相当、捻くれ者！

2017/05/25(木) 13:09:18.12

>>668
ありがとー

2017/05/25(木) 13:38:00.17

完全にスレチな話題延々してるのとどっちもどっち

2017/05/25(木) 16:35:11.41

下のドキュメントを読むにCopy On Writeで最適化する場合にはprotocolやclassでラップせよと言ってるんだけど
Copy On Writeって関数引数に単純なstruct型を渡した時の値渡しには適用されないって認識であってる？

教えてエロい人

https://github.com/apple/swift/blob/master/docs/OptimizationTips.rst
Advice: Use copy-on-write semantics for large values

2017/05/25(木) 17:14:53.66

どこに
>Copy On Writeで最適化する場合にはprotocolやclassでラップせよ
とか書いてあんだよ

>Copy On Writeって関数引数に単純なstruct型を渡した時の値渡しには適用されないって認識であってる？
んなわけねーだろ

2017/05/25(木) 17:36:25.00

あ、すまん、Advice:の節を注視して前の節を飛ばしてた

> When we copy values (the effect of assignment, initialization, and argument passing) the program will create a new copy of the value.
値渡しはコピーするってしっかり書いてあったわ

2017/05/25(木) 17:42:45.12

structは常にコピー
このstructはcopy on writeです、という場合も便宜上そう言ってるだけで、実際は中の参照型のストレージをcopy on writeしてるんであってstruct自体は常にコピー
ただしin-out引数だけは例外的にstructでも参照渡しになる場合がある

2017/05/25(木) 17:46:16.79

copy on writeだから、コビーの必要性が生じた時にコピーが発生するんだろ
structであっても参照するだけならコピーはしない（はず）

2017/05/25(木) 17:59:30.69

>>674
だよなー、昔もSwiftはCOWで処理するからコピーするわけない!!みたいな奴がいて
ずっと首を捻ってたから、このドキュメントで裏付け取れて良かったわ

>>672, 675
お前はフィーリングだけで物を言わず、COWの実装を学べ

あと>>671でprotocolでラップとか言ったけど意味ないな
protocolはI/F切るだけのものだから、class/structで差をつけないと参照/値渡しには影響ないわ

2017/05/25(木) 18:01:40.91

structの参照渡しのためのin-out parameter(inout)は使いたくないと思った
それするなら、最初からclassでAPIを設計しろというね

2017/05/25(木) 18:02:56.87

>>676
常にコピーなら、コピーオンライトとは呼べないな

2017/05/25(木) 18:12:33.09

>>677
inoutを指定しなくないから、クラスにするって考え方がそもそもおかしい

2017/05/25(木) 18:31:58.93

>>678
メモリ操作としてのコピーと、変数への代入時の複製を混同すると、そういう訳のわからない議論になるね
structはコピーオンライトと言っても、osやハードウェアのレイヤーになるとclassであっても必要に応じてコピー(と消去を組み合わせた移動)を行ってるんだけどね。
swiftのレイヤーでは、常にコピーされるって言って良いんじゃないかな
コピーの為に支払うコストがいつ払うことになるか、そもそも払う必要が生じるのか、っていう部分にコピーオンライトの概念が関係してくるだけなんだから

2017/05/25(木) 18:40:08.35

>>680
ごちゃごちゃした理論は言語設計者の領域の話で
プラグラマ視点でのコピーオンライトという文脈では書き換え時にコピー（コスト）が発生するという単純な理解で特に問題ないだろ
じゃないと、Structは常にコピーが発生するからデータの粒度をなるべく小さくして関数への引数渡しも注意しないととか余計な設計負荷を意識しないといけなくなる

2017/05/25(木) 19:05:12.83

structは値渡し、classは参照渡し、Array Structの中身はCOWで処理、プログラマはこれを意識して最適化しろ
と>>671のリンク先で言ってるわけだが？
プログラマのレイヤーで考えるべきことが提示されてるのに、なぜそれを見ようとしないのか

2017/05/25(木) 19:55:10.84

でかいデータをstructにつっこんで扱う時に注意すべきことが書いてあるだけだろ
つまり代入が頻繁に発生する状況でも、そのプロパティに実際にアクセスがあるまでコピーを遅延させるテクニックについて触れられてるだけ
別に関数の引数に値型を使うなとかとんちんかんなことは書いてないな

2017/05/25(木) 21:10:12.75

SwiftでCOW意識する人なんているんだ。
そういう人はC++とかRustとか使えばいいのに。

2017/05/25(木) 22:26:04.80

最適化しない場所も含めて意識くらいはするでしょ
その程度のことで言語を変える理由にはならんよ

むしろStructでCoWという設計だからこと気兼ねなく渡せるってことに気付いた方がいい

2017/05/26(金) 05:16:56.16

誤: StructでCoWという設計だからこと気兼ねなく渡せる
正: Array StructでCoWという設計だからこと気兼ねなく渡せる

どうしてもSturct全般でCOWが適用されると思い込みたいアホが食いしばってて笑う

2017/05/26(金) 07:23:41.84

>>686
「Structが」じゃなくて「Structで」な
Arrayに限らず、StringやDictionaryなどのstructでCoWを実装したもの全般

classでCoWを実装する場合は使う側が明示的にcopy()clone()などを呼ぶかinitを使う必要があるが
structでは代入,引数渡し,戻り値がコピーセマンティクスなので透過的に扱うことが出来る

2017/05/26(金) 08:03:17.32

COWの話題から、いつの間にか参照渡し/値渡しの解説になっててワロタ
結局はSturctでCOWが常時適用されるわけじゃないから気をつけようってこったな
参照渡し/値渡しの違いを知らないLL言語勢もいるかもしれんが、別の問題だから気にしない

>>671のReducing Dynamic Dispatchの節も面白い
SwiftはObjective-Cと違ってダイナミックディスパッチを減らす機構を持ってるぜ、と
これを徹底的に使い倒したら、局所的にはObjCよりSwiftの方が性能よくなる可能性が微レ存？

2017/05/26(金) 08:31:19.29

細かいところだけどclassは参照の値渡しでinoutは参照渡し

2017/05/26(金) 08:45:20.46

>>676
protocolにまつわる言い回しを色々見ますが、どれが適当なのでしょう？

1. protocolを切る
2. protocolを当てる
3. protocolに準拠させる

すべてadding protocol confromanceの訳語だとおもうんですけど。

2017/05/26(金) 08:49:45.12

最近のCPUはSIMD命令(SSEとかAVRとか言われるやつ）を内蔵していて、
でかいStructも一発でコピーできるって、理解は正しいっすかねぇ？

512bitレジスタが32個あって、しかもその32レジスタはペアで使える。
って事は、512bit x 32個 = 2Kbyteを一発でレジスタ -> メモリへmoveしたり
メモリ -> レジスタloadできる。

この理解はOKっすかねぇ。

2017/05/26(金) 10:19:08.37

>>689
in-out引数は参照渡しじゃない
in-out引数のセマンティクスはあくまでcopy-in copy-outで、最適化で参照渡しになる"場合もある"だけ
リファレンスではin-out引数が参照渡しであると想定したコードを書いてはいけないとはっきり言ってる
https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/Declarations.html#//apple_ref/doc/uid/TP40014097-CH34-ID545

var i: Int = 0 {
willSet { print("willSet: ¥(newValue)") }
}

i = 1 // prints "willSet: 1"
i = 2 // prints "willSet: 2"

func f(_ v: inout Int) {
v = 3
v = 4
}

f(&i) // prints "willSet: 4"

参照渡しなら"willSet: 3"と"willSet: 4"両方表示されるはずだけど
実際には関数に入るときにiの値がvにcopy-inされ
関数から出るときにvの値がiにcopy-outされるので
copy-out時の"willSet: 4"しか表示されない

2017/05/26(金) 10:43:47.67

>>692
すんばらしい、説明

2017/05/27(土) 14:04:16.20

>>692
え…
参照渡しと値渡しで違う動作するとき
動作がどっちになるかわからんってこと？

2017/05/27(土) 21:00:43.52

>>694の心の声
(やべぇ、まじかよ…。バグ仕込んじまった…)

2017/05/27(土) 21:48:41.96

inoutで渡された配列変数のオリジナルを関数内で操作しても副作用はないみたいただけどな

var a = [Int]()

func f(_ v: inout [Int]) {
v.append(3)
a.append(4)
v.append(5)
}

a.append(1)
f(&a)
a.append(2)

print(a) // [1, 3, 4, 5, 2]

ただ、それを想定するなということなんだろ

2017/05/27(土) 21:57:51.65

SwiftってiOSアプリ以外に広がる可能性ある？

2017/05/27(土) 22:13:54.38

少なくともwillSetがある場合は参照渡しの最適化が掛からないようだね
以下のAはcopy-in, copy-outになっていて、Bは参照渡しになってる
http://swift.sandbox.bluemix.net/#/repl/592977d0d72c2a7516859cca

2017/05/27(土) 22:20:21.28

>>696
いやそれ副作用ある状態じゃん
関数終わった時点で
a=1,4
v=1,3,5
だからoutでvがaに上書きされて
1,3,5,2 が出ないといけないはず

2017/05/27(土) 22:21:46.44

>>696
var a = [Int]() { willSet{ } } にしたら [1, 3, 5, 2] になるね

2017/05/27(土) 22:26:06.26

えええええ
ほんとに動き違うのかｗｗｗｗ

2017/05/27(土) 22:26:19.82

>>699
aの内容を変更するためにf()にaを渡したのだから、f()の中ではaとvは同じ扱い
なので、inoutの仕様からすれば、>>696の挙動が自然だと思うけど

2017/05/27(土) 22:30:22.71

willSetの有無で挙動が変わるのはいただけな
デバッグで混乱する元になる

2017/05/27(土) 22:31:17.31

>>702
>>692のリンク先
In-out parameters are passed as follows:
1.When the function is called, the value of the argument is copied.
2.In the body of the function, the copy is modified.
3.When the function returns, the copy’s value is assigned to the original argument.

コピーされるて書いてあるやん！

2017/05/27(土) 22:38:43.72

>>704
そこに
As an optimization, when the argument is a value stored at a physical address in memory, the same memory location is used both inside and outside the function body. The optimized behavior is known as call by reference
とも書いてある。参照を渡して最適化されると。
それに依存して関数内で参照元にアクセスするなとも書いてあるけど

2017/05/27(土) 22:41:57.41

>>705
うん、>>692を誤読してた
動作変わるのは最適化って言わねーよ！

>>696ってほんとに試したんか

2017/05/27(土) 22:47:16.42

>>706
Playgroundにコピペして試してみればいいだろ

2017/05/27(土) 22:49:30.62

Write your code using the model given by copy-in copy-out, without depending on the call-by-reference optimization,
so that it behaves correctly with or without the optimization.

…最適化と言い張ってるがこれはひどい

2017/05/27(土) 23:01:24.62

このぐらいの最適化はやってくれた方がありがたい
参照渡しの方が確実にパフォーマンス上がるし、通常の使い方で副作用もない
副作用があるようなら書き方に問題があるだろ
inoutで受けた変数のオリジナルにアクセスするコードにワーニングぐらい出してくれたら
とも思うけど、まだそこまで面倒は見きれないんだろ
ただ、最適化の恩恵にあずかりたいなら、willSetなんかは入れない方がいいみたいだな

2017/05/27(土) 23:07:17.91

>>706
いや最適化だよ
参照渡しにしたとしても、外形的にcopy-in copy-outした場合と全く同じ動作をする場合にだけ、参照渡しに最適化される
ただ、>>696みたいなコード書くとその最適化の前提がぶっ壊れるから絶対するなとリファレンスでも言ってるだけで

リファレンスにはっきりやるなと書いてることをやって壊れたからってそれはプログラマの責任でしょ

まぁ将来的にownershipが入れば>>696みたいなコードもちゃんとコンパイルエラーにしてくれるようになると思うよ

2017/05/27(土) 23:47:08.68

willSetがあるとmutating funcもself自体がcopy-in copy-outになった
これもリファレンスのどこかにあるのかな

struct A{
var v = [Int]()
var onAppend: (()->())? = nil
mutating func f() {
v.append(1)
onAppend?()
}
}
do {
var a = A()
a.onAppend = { a.v.append(2) }
a.f()
print("willSetなし", a.v) // [1, 2]
}
do {
var a = A() {willSet{}}
a.onAppend = { a.v.append(2) }
a.f()
print("willSetあり", a.v) // [1]
}

willSetなし [1, 2]
willSetあり [1]

2017/05/28(日) 00:12:22.92

willSet/didSetの挙動が怪しすぎるな
バグなのかもな

2017/05/28(日) 08:47:45.67

>>712
いや挙動的には予想通りだよ
didSetはともかく、willSetの方は呼ばれたコード内では「変更前のオリジナル変数」と「変更後のnewValue」が用意されてるから別の実体作って変更してる
想像だけどinout引数を持つ関数側はバイナリコードレベルでは常に参照で受取るようになっていて
willSetがある変数でmutating funcやinout渡しをすると、呼ぶ側が一時変数作ってそれを渡すコードを生成してると思う

var a = A() { willSet{ } }
a.f() //mutating func f()
　　　↓
var a = A()
func a_willSet(_ newValue:A) { }
do {
var tmp = a
tmp.f()
a_willSet(tmp)
a = tmp
}

inoutの場合は a.f()とtmp.f() が f(&a)とf(&tmp)になるイメージ

2017/05/28(日) 09:31:38.11

この挙動を理解してなければ、structにwillSet/didSetを実装してパフォーマンスに意図しない影響を与える可能性があるな

2017/05/28(日) 11:21:48.67

>>697
ないっしょ…
なぜSwiftとかいう自己満発展途上言語なんか使ってるかって言ったらApple様ご指定だからってだけだし

2017/05/28(日) 11:31:20.31

mutatingはselfをinoutで渡す
a.f() // これは
A.f(&a)() // これと同じ
なので一般のinout引数と同様にmutatingメソッド内のselfもセマンティクス的にはcopy-in copy-out

ただmutatingが暗黙にselfをinoutで渡すって説明はリファレンスには見つけられなかった
リポジトリのdocsに放り込まれてる文書群ではしばしば言及されてるけど

2017/05/28(日) 12:29:40.83

気軽にプロパティ変えたつもりの1行で、コピーが3回も（うち2回は配列全体のコピー）発生するのね
structのwillSetは曲者だな

struct Weapon {
var name: String {
willSet { print("new wepon name = ¥(newValue)") }
}
}

struct Monster {
var name: String
var weapons: [Weapon] {
willSet { print("new weapons = ¥(newValue)") }
}
}

var monsters = [
Monster(name: "Goblin", weapons: [Weapon(name: "Knife")]),
Monster(name: "Orc", weapons: [Weapon(name: "Sword")]),
Monster(name: "Dragon", weapons: [])
] {
willSet { print("new monsters = ¥(newValue)") }
}

monsters[1].weapons[0].name = "Mace"
// output
/*
new weapon name = mace
new weapons = [Weapon(name: "Mace"]
new monsters = [Monster(name: "Goblin", weapons: [Weapon(name: "Knife")]), Monster(name: "Orc", weapons: [Weapon(name: "Mace")]), Monster(name: "Dragon", weapons: [])]
*/

2017/05/28(日) 12:30:23.95

クラスで実装すれば、wellSetあってもコピーはプロバティに対しての一回だけ
class Weapon {
var name: String {
willSet { print("new wepon name = ¥(newValue)") }
}
init(name: String) {
self.name = name
}
}
class Monster {
var name: String
var weapons: [Weapon] {
willSet { print("new weapons = ¥(newValue)") }
}
init(name: String, weapons: [Weapon]) {
self.name = name
self.weapons = weapons
}
}
var monsters = [
Monster(name: "Goblin", weapons: [Weapon(name: "Knife")]),
Monster(name: "Orc", weapons: [Weapon(name: "Sword")]),
Monster(name: "Dragon", weapons: [])
] {
willSet { print("new monsters = ¥(newValue)") }
}

monsters[1].weapons[0].name = "Mace"
// output
/*
new wepon name = Mace
*/

2017/05/28(日) 12:35:53.43

Swift初期にJavaScriptに似てるからWeb屋が参入してくるとか言ってた人もいたけど全然違うしSwiftはObjective-Cより仕様が複雑になってきたね
でもおかしなコードはコンパイラがビシバシ教えてくれるし仕様を詳しく知らなくてもとりあえずコードを書く事はできるかな？

2017/05/28(日) 22:04:52.22

Swiftけっこう難しい
Objective-Cは形式張っていてコードがやたらと長くなるだけで実はそんなに難しくない

2017/05/28(日) 22:35:10.01

>>720
俺もSwift難しい。
structにprotocol適用したり、protocol extensionとか。

2017/05/28(日) 22:44:58.49

詰め込みすぎて開発者のスキルでコードが変わりすぎるのが難点

2017/05/28(日) 22:57:25.17

>>720
C知ってればハードル高くないからなObjCは

2017/05/28(日) 23:22:08.09

そのCがハードル高いからな初心者には

2017/05/28(日) 23:28:56.75

SwiftとCのどっちがハードル高いかって言ったらCとは言えないけどな
Cのシンタックスをベースにしてる言語は多いから、初学者にSwiftとC
どっちをやった方がいいかって言われたら間違いなくCだわ

2017/05/28(日) 23:30:24.66

初心者にポインターは結構ハードル高いと思うけど
あとメモリ管理にシビアな所とか

2017/05/29(月) 00:25:02.54

Cもわからんようなもやしエンジニアが増えると思うと先が思いやられる
ソフト屋もハードウェアに近いプリミティブな部分の理解は必要なんだけとな
そういう意味でCは高級アセンブラ的なバランスがちょうどいい

2017/05/29(月) 00:38:37.93

>>726
ポインタが難しいって言ったって、結局ポインタ的なメモリの知識はあった方がデバッグでメモリ周り疑う疑わないに直結するしなぁ。。。

2017/05/29(月) 00:47:58.23

でも今は簡単なゲーム作りたいとかなら特にポインタの知識なくても作れちゃうからなぁ
初心者にC言語でゲーム作ってだと難しいと思うけど、Swiftなら割と簡単
モグラたたきとかジャンケンゲーム程度なら初心者でも2,3日で作れるかも

2017/05/29(月) 00:57:45.02

誰もポインタないと作れないなんて言ってない。
ポインタの知識はトラブった時にトラブルの原因の候補にメモリが上がるか？どう状態かを推測出来るか？ってのに直結する。
ポインタと言うか、メモリの構造を知らなけりゃトラブルの原因として候補にすら上がらない。
下手すれば永延と原因分からないまま、プログラムは未完に終わる。

2017/05/29(月) 01:03:25.64

そんなこと言い出したら究極的にはコンパイラの癖とかハードの特性とかまで知らないとデバッグできないことになる
初心者にそこまで求めるのは余りにも遠い道のりになる

2017/05/29(月) 01:19:59.07

そこまで言わんが、初心者と言えどもCPUとメモリの仕組みは理解してからプログラミングは始めて欲しいものだが。

体験して見たいだけなら兎も角、プログラマになりたいんならね。

2017/05/29(月) 06:40:45.44

kotlin nativeがllvm対応してるらしいのでiosでもkotlin使えそう。
となればswiftはもういいかな。

2017/05/29(月) 07:01:38.32

フフってなった
昔、SwiftもLLVMだからどこでも動くって言ってたなぁ

まぁKotlinは頑張ってポーティングしてるようだから
実用性はさておき動くんだろうけど

2017/05/29(月) 08:51:21.58

>>722
C言語のソースも、人によって全然違うけどなぁ。
とくに、Headerファイルのマクロ定義によってソースの印象がガラッと変わる。

2017/05/29(月) 09:10:28.76

>>735
Cと比較したらCのがやりたい放題に決まってるだろ…
関数をアドレス指定で直接コールできる言語やぞ…
比較対象がおかしいわ

2017/05/29(月) 10:41:09.25

ポインタとか分からんレベルの人にはやりたい放題出来ないがんじがらめの世界の方がいい気はする
柔軟性はObjective-Cで安全性はSwiftなイメージ

2017/05/29(月) 11:13:19.98

>>733
Kotlin/Nativeなんてのがあるのね！
知らんかった。JVM無しで動くコードが作れるのかな？

2017/05/29(月) 11:14:56.30

It is not a fully functional release yet,

Kotlin/Nativeがどの程度動くのか？気になる。

2017/05/29(月) 11:27:53.51

>>729
ポインタ分からないって人は、参照型の値型の違いが理解出来なくないか？

2017/05/29(月) 12:04:20.43

参照型と値型の違いがわからなくても使い方さえ理解できれば簡単なアプリは作れるからな
ある程度の最適化はコンパイラがやってくれるし、ハードの性能も上がってるから、多少の冗長性は無視できる
C言語だとそうはいかない
ポインタを知らないとまずまともなアプリはつくれない
外部のライブラリを利用する場合もポインタの知識は必須になる
ポインタの理解が参照型の理解の助けにはなるだろうけど厳密にはポインタと参照型は同じものでもないし

2017/05/29(月) 12:14:04.16

それは、ポインタを知らなくても使い方さえ覚えれば簡単なアプリは作れる、っていっても同じじゃないか？

2017/05/29(月) 12:33:55.33

ポインタの場合は概念を理解しないで使い方だけ覚えるってのはちと無理がある
Swiftの参照型は概念をきっちり理解できなくても、大概動くものは作れるし、変なことやろうとしてもIDEやコンパイラが注意してくれる