Swift part7 [無断転載禁止]©2ch.netYouTube動画>1本 ->画像>2枚

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

関連スレ
let s: プログラミング言語? = Swift[2]
http://anago.2ch.net/test/read.cgi/mac/1408755325/

プログラミング言語Swift 3
http://anago.2ch.net/test/read.cgi/mac/1408762479/

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

Xcode part13 [転載禁止]©2ch.net
http://anago.2ch.net/test/read.cgi/mac/1424907278/

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

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

swift覚えるよりiOSとUIKit覚えたほうが勝ちだぞ＞初心者
今swiftでググってもカスみたいな情報しかないから
swiftは7.0あたりからやろうぜ

俺は174*83*27、柔道三段・剣道四段・空手二段、ガチムチの機動隊員
日夜激しい訓練と任務に明け暮れてる
だから股間のピストルはいつも暴発寸前だ！
お前の菊門に発射させろ！
25〜35くらいの同体型の短髪雄野郎、激しく盛ろうぜ！
捕縛術の心得もあるので緊縛プレイを求めてるＭ野郎歓迎だ！
特に希望があれば制服プレイも可
複数も可
非番の日なら都内なら連絡寄越せばすぐ逮捕しに行く！
ケツマンおっぴろげて神妙に待ってろ！

>>2
それをいったらobj-cだって新旧で結構変わったと思うで
publicとかprivateみたいなkeywordをobj-cで見つけたらそれは古いってこと。

swiftだったらなんだろう
NSErrorを直接扱ってたら古いコード？

>>2
アンチスレにどうぞ

>>2はほっといて、初心者はSwiftで iOS, UIKit を学べば良いなw
JavaScriptやってたらなんとなく文法似てるからObj-Cより親しみ易い

Swiftでdelegate protocolを自前で定義してたら古いObj-C脳のクソ設計だと思う
@objcな public インターフェースなら苦笑しながら使うかな

Swiftからやると他の言語できないクソ脳エンジニアになるよ！

日曜プログラマはSwiftで遊んでおけばいい
仕様がコロコロ変わるSwiftを今使うプロはただの馬鹿ってだけ

>>8
これに尽きるんだよな
みんな遊びでやってるのに煽りに踊らされたObj-Cのプロが突っ込んでくるだけで

>>6
イマドキ、Obj-Cでもdelegate定義したら古いコード
よって、 Swiftでdelegate定義したら設計者の頭カチ割るくらいでいい

delegateの代わりに何を使うの？

callbackじゃね？
もう@Nullable annotation使ってjavaでいいんじゃね？

obj-cにもnilableキーワード追加されてるんだけどなぁ
なぜそこでJavaを推すのか、コレガワカラナイ

ゴミはゴミ箱へ
アンチはアンチスレへ

protocol指向なのにdelegateパターン否定してどうするのwww

>>10
Handler使うと良い
実態はインライン関数程度に最適化されるので性能も悪くない
今時 Delegate が許されるのは(ry

delegateという考えは古くないと思うし現役だと思うけど。
仮にtableViewを再実装するとしてdelegate使わずどうするわけ？

>protocol指向なのにdelegateパターン否定してどうするのwww
プロトコル指向とdelegateパターンの関連がよくわからん

古いシステムAPIはNSURLConnectionからNSURLSessionへみたいにアポー様が書き直すの待つ
どう書き直すのがベターかはNSURLSession参考にしてどうぞ

最近追加するAPIはハンドラばかりじゃないかね

テーブルビューがデリゲートやめてクロージャだらけになったら悪夢だな
URLConnectionは使い捨てることが多いからクロージャと相性良かっただけだ

クリックイベント拾うだけなら1つで済むと思うけどな
全APIをクロージャーに書き換えずとも、プロパティ操作で良いし
Sessionも細かい制御するコード書いたらクロージャーだらけよw

>>13
アンチスレなんてあるの？

ここがアンチスレだよな？

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

馬鹿かよ
クソスレ立ててんじゃねぇ

そもそもdelegateは機能の移譲なわけだから、
クロージャーを使う、使わないは的はずれ。
多分obj-c時代、block構文がなかった時に、
クロージャーを本来使ったほうがいいところをdelegateを使って実現しているところがあって、そのことを誰かが指摘したことを聞きかじって、
delegateは悪だって思い込んじゃったんだな。

昔AlertViewが本来クロージャーを使うところをdelegateを使っていたけど
今置き換わったAlertControllerはクロージャーを使ってる。
まだ若干残っているかもしれんけど、まぁ自分で直して使えばいいし
俺はrxSwift使うからどっちでもStreamにしてしまうけど

NSURLConnection だって色々とやろうとしたら callback block なんかじゃやってられんしな

NSURLSessionだってクロージャは一部でdelegateメソッドがたくさん存在してるよ
クロージャは便利だがそれで全て置き換えられるわけでは無い

確かにその場しのぎとしてクロジャはオブジェクト不要レベルの凄まじい文字通り型破りが出来るけど
delegateはオブジェクト同士のやり取りに大枠を作るパターンなので大枠がないと必要不必要の話になりにくい

Obj-Cで使う分には良いがSwiftでdelegateの宣言も利用もキモいがな
アレはobj-c互換の苦肉の仕様は体を張ったギャグだわw
不思議に思わないとか、意味分からないヤツはホントにswift使ってんの？って問うレベル

こういうギャグをちょいちょいはさむから swiftはやめらんねえ

？
なんかキモいことあったっけ？

AppleはSwiftゴリおしやめるらしいぞ！
Swifter哀れwwwwwwwwww

ゴミはゴミ箱へ、アンチはアンチスレへ

NSプレフィックス無し、nil返さないcocoaまだ？
swift3.0に間に合うのか？
4.0でまた非互換？構文変わるのか？

swiftそのものがお笑いネタだろ？
swift推してる連中はAndroid厨が面白がって煽ってるだけ
まともなiOSエンジニアが信頼性のないswiftなんか使うワケないだろハゲチビ

Swift3.0ソースが公開されたら
Optional型を排除
map、flatmapなどの直感的にわからない機能の排除
してSwift-作るよ

ゴミはゴミ箱へ、アンチはアンチスレへ

Apple信者 分裂
obj-c:山口組
swift:神戸山口組
抗争状態

何でSwiftマンセーしないとゴミなの？

>>29
自前でdelegate宣言して、delegateで宣言したメソッドを呼び出す、までやってみろ
メソッド名、キーワード名はきちんとObj-Cお作法に合わせる前提でな

TableViewを外から使っててても何か変、と思うが
自分で実態書いてたらすごくバカっぽいと気付く

SwiftってKVO使えないんだな・・

身のないバズワードで煽ってるからゴミなんじゃないの？

KVOは個々にプロパティ切った方が安全でそっちが使われてるし
無駄機能の提供分処理オーバーヘッドかかるから削るわ、、、
って公式ドキュメントで説明あったはず

何でnil禁止しないの？

どちて坊やは一休さんの世界へお帰り
ゴミはゴミ箱へ、アンチはアンチスレへ

Xcode更新(Swift 2.2)キタ
そして、++, --のdeprecateが入ったwww
これはワーニングの嵐の予感、ワーニング0の商用開発だと泣けるな
他にも細々機能追加あるので、もう一回遊べるドン

>>30
マジで？マジなら朗報じゃねぇか

>>31
>>42
ID変えてご苦労さま

ゴミはゴミ箱へ、アンチはアンチスレへ

ゴミはゴミ箱へ、アンチはアンチスレへ

i++って i = i.advance() で置き換えるのかと思ったら、i += 1 で置き換えるのな
まだ advance のI/F宣言もなされてないようだし、秋にまたConvert To Last Swift Syntaxかね
この程度ならまだバグなく差し替えられるだろうから良いけど(1.xの頃のバグのせいでConvertは信用してない

>>46
>>47
IDパラ使いでご苦労さま

>>48
ところで優柔不断なクリスの気まぐれを逐一フォローし続けるのは時間の無駄だよ
Swiftは仕様が固まってから使えばいい

swiftはバージョン進み過ぎでgolangより歴史が浅いって忘れてしまう
けど仕様の破壊的変更が大きいから仕方ないのかな。
golangは2.0になる気配が全くしない。それだけ安定しているってことだけど、
スレは伸びない。
swiftは3.0もすぐにもでそうだけどいつリリース予定だっけ？

10月

他大手会社が言語開発してるから自分もやらなきゃ(焦り
で始まったような言語だからな

TypeScript, Go, Rust, Kotlin, Nim, etc.あの頃は結構大量に出てた気がする

AppleらしくObjective-C 3.0で進めばいいのにね
バカだねぇ

ゴミはゴミ箱へ、アンチはアンチスレへ

swift関数型みたいな事出来たっけ？？

Kenokabe先生の所へどうぞ

Swiftで下記の処理を書けなくなると聞いたのですが、本当ですか？

for var i = 0; i >= -10; i -= 1 {

}

ggrks
https://github.com/apple/swift-evolution/blob/master/proposals/0004-remove-pre-post-inc-decrement.md

>>59
開発者なんかおいてきぼりでacceptされた--, ++はもうどうでもいいんです
気になっているのはfor文のことなんですが

proposal読め、ゴミ

なんでそんなにプリプリしてるんですか？
これですよね？
https://github.com/apple/swift-evolution/blob/master/proposals/0007-remove-c-style-for-loops.md
よんだんですが、forループはインクリメントしかあたまにないのか、デクリメントに対するSwiftコード例が見当たらなく…

ここで話題になってる
http://echo.2ch.net/test/read.cgi/tech/1458491343/

何ですか？そのｸｿｽﾚは…。

Whileで書き換えろってことかな

ループローカル変数のスコープ切るのに
do {}で括るのがウザい

>>58
for i in 0.stride(through: -10, by: -1) {

}

とにかく変わった感を無理やり醸し出してる感が
鼻につく「嫌な感じ」の言語
それがSwift

obj-cは大豆、swiftは納豆
大豆はそのままでは食べられないし手間がかかるし面倒だがそもそも枝豆で常温保存もきくし豆腐にも納豆にもなる
納豆は高機能食品で身体にもいい、アレンジ料理もある、でもかき混ぜないと美味しくない納豆でしかない

ゴミはゴミ箱へ、アンチはアンチスレへ

>>67
ほんそれ
わざわざ自分からアンチ産み出していくスタイルは新しいよな

ゴミはゴミ箱へ、アンチはアンチスレへ

>>51
Wineって10年くらい1.00にならず枯れたソフトもあるのでバージョンは信用ならない
あれが1.00出した時はびっくりしたよ

わいの半年前の知識通用するかこのスレ見てたら不安になってきた
たった半年だぞおい

2.xはそんな変わってないじゃん
betaから1.xにかけては半年も前の知識が通用するわけがなかったけど

Swift初期は半年毎にビルドエラーの嵐でおもろかった
ここ一年はまったく動きが少なくておもろない

Swift 3.0のコンパイラはまだかね
オープンソース()なら段階的にそろそろ出してもよかろう

オープンソースなんだから自分でビルドすればよかろう

コンパイルくらいは自分でするんだけど実装も済んでたかなと
Proposalで仕様は切ったけど、実装は内々だよだとお手上げだから

そして、Swiftは終わった・・

ゴミはゴミ箱へ、アンチはアンチスレへ

ブランチ出来てたので人柱になってみるか

>>77
FoundationはいろいろとNot Implementedだったような気がする
GitHubには出てこない社内プロジェクトで進んでるんだろうか。それともGitHub上のが全てで完全にオープンで進めてるんだろうか。

iPhone無かったら見向きもされなかったクソ言語と
iPhone無かったら生まれなかったクソ言語でヤリ合うスレはここですか？

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

なんでそんなに必死なの？

>iPhone無かったら見向きもされなかったクソ言語と
OS Xで使われてたしコミュニティもあって実績も歴史もあった
iPhoneでより普及したってだけ

Swiftの負けを認めてるからだろ・・

ゴミはゴミ箱へ、アンチはアンチスレへ

https://developers.eure.jp/event/10-tips-when-moving-from-objective-c-to-swift-ja/
これはいい記事

パターンマッチの例が無理矢理使ってる感じで気に入らんな
いくつかは素直にwhereやas?で書いたほうがずっと可読性高いはず

> シングルトンの代わりに staticの関数やプロパティを使用する enum で作成する
enumをそういう用途で使ったらダメだろw
バッドノウハウにバッドノウハウを重ねたような実装に笑うわ
いっそシングルトンモデルは「悪」と諦めた方が良さそう

シングルトンをenumにしろってのも気に入らない
structとclassだとインスタンスの初期化ができてしまうからっていうけど
initをprivateで宣言すればいいだけだし
何よりenumのセマンティクスを破壊してるのがバッドノウハウ感しかない

被ったwスマンw

do { }でコード整理ってのもなんだかなー感しかない
全体的にこの人のコードは自己流の変な工夫が多くて一般的な良いコードではないと思う

反面教師としていい記事だったな
全面的に悪いというわけじゃないと思うので、良い所だけ参考にしようじゃないの

とりあえずこんなにSwiftは素晴らしいんだぜって思わせたいという必死さは伝わった

>>89
パターンマッチの例は普通だと思ったんですが
どの辺の例が無理矢理なのか詳しく

普通かどうかは置いといて、メジャーバージョンアップでビルド通らなくなりそうだなぁ、とは思ったぞ
1.系の頃ならマイナーバージョンアップでビルド通らなくなるコードだろ、アレ

スコープを絞る目的でdo{}を使えというSwiftの仕様がキライ。
C同様にシンプルな{}のサポート入れてほしい。

swiftの仕様じゃなく、ブログ書いたへっぽこプログラマのバッドノウハウ
スコープ絞ること自体、イマドキのプログラミング事情に則してなくね？

昔は関数ブロックにしたら、バイナリコード増加や
関数呼び出しの処理低下になるからブロックが良しだったんだろうけど
コンパイラの最適化が賢い今なら無駄なテクニックだろうよ

そもそも容量や性能気にするヤツは swift 使うな

関数foo(block: (() -> ())? = nil)があったとして
foo()の次に{}が来たらクロージャになってしまうからSwiftの言語仕様じゃ無理だろう

>>99
スコープ絞るのは人間のケアレスミスを防ぐためだろう。

>>100
なるほど、それでdoが必要なのか
3.0で何とか仕様変更して欲しいな

rustみたいに文末;必須にするか、、、
rustはrustの信念で;採用してるけど、;の意味論が分かりづらく評判イクナイ

goはどうしてるんだっけかな

>>103
goは暗黙の ; を導入している

つまり関数宣言として

func hoge() {
XXXX
}
であり

func hoge()
{
}
は

func hoge();
{

}
とみなされるのでシンタックスエラー

正直 {の改行位置の言語による強制は好き。構文規約じゃなく言語仕様で縛ってほしい

ここはクソ言語のスレじゃないのかよ

挑戦的だが流行らなさそうな仕様だなw
コードフォーマットの強制はpythonもそうだけど、人を選んで流行ってないからなぁ

pythonは多目的汎用スクリプト言語としては
世界で一番でかいシェアだが…

python以外のメジャー言語だと皆無じゃん？
その制約があっても他にメリット多いから使われてるけど、他言語が追従するメリットじゃないんだろう
# python好きだし別に嫌悪感ないけど、全てを崇めるほど信者じゃない

swiftはgofmt程度のフォーマッタは提供して欲しいかのう
Xcodeあるからイラネ、とまったく期待出来んが

python流行ってない
↓
そんなことはない
↓
python以外は皆無

どういうことなのか

do {
}
使うくらいなら関数宣言の{位置の強制でいいと思うよ

func () {
}
と
func()
{
}
のどっちがいいとか正直どうでもいいしswiftlintとかでどっちがに強制するでしょ。どうせ。

>>109
python以外で使われてないからその文法が流行ってない
読み取ってくれよ

コードの柔軟性が減る独善的な決め打ちはやだなぁ
GoogleもApple程度(以上？)に独善的な会社になったからアイツに全力追従は生理的な恐怖感があるわw

コードの柔軟性を嫌ってる人がswiftを持ち上げてるんじゃないの
いわく、バグが入り込む潜在的なリスクが上がるだの
メンテしにくくなるだのって

Swiftはまだまだ混沌としてるな〜

正直swiftのクロージャーの書き方がシンプル過ぎて危険な気がしてきた。
特に$0を使うときはinを省略できちゃうとか
おかげでただのブロックをdo{}にしなきゃいけないのはどうなんだろう。

NSURL.fileURLWithPath()で、nil返す事があるってドキュメントに
書いてあるのに、optional定義になっていないのは何故なんだぜ。

こういうのは修正されたらされたで、ソースがコンパイルエラーになるよなぁ。

そもそもnilを絶対返さない事って可能なのか？
インスタンスの生成は、大元のmallocが領域確保できずにnullを返す可能性があるだろ。

スタックメモリから確保した値型

という揚げ足はおいといて、初期にnilable constructorがなかった辺り
理想としてnilを返さない在り様は考えたかったんじゃないかなぁ

>>115
とりあえず明示的にOptionalで宣言しとけば大丈夫
let url: NSURL? = NSURL.fileURLWithPath("")

https://bugs.swift.org/browse/SR-863

>>117
オブジェクトがヒープに確保されるかぎり無理だな。

おお、SwiftのバグデータベースはDashboardなのか。会社でも使ってる^_^

なるほど、強制的にOptionalに代入して対処するのか。サンクス。

DashboardじゃなくてJIRAだったorz

やっぱりSwiftはまだ無理だな

ゴミはゴミ箱へ、アンチはアンチスレへ

>>115
その辺り、バージョンアップの度に修正入ってビルドエラーになってる気がするので
見つけたら直す程度の気分で修正を続けて頂きたい

ゴミはアンチスレへ、アンチはゴミ箱へ

変なのにいつかれちゃったな

アンチアンチ騒いでんのはただの荒しだな

アンチスレとこっちのスレで分断煽りしてるやつがいるんだよなあ

swiftのクラスってメンバ変数定義できないんですか？

>>127
Swift推進部隊の常駐監視員さんですか？

>>128
ゴミはゴミ箱へ

>>119で考え直したが
昔nilable constructorがなかったのって
もしかしてスタックからメモリ確保した時と同じ振る舞いで良しと思ったのか

あまりにもバカっぽい仕様で訂正入ったけど
当時の訂正時の今さらかよと笑ったけど、今なら分かる

全部が値渡しで済むわけじゃないし。
確保した領域のアドレス値渡しとそのエイリアスという方法は合理的なんだよ。

nilについては、計算結果がnilになるケースがあるのは当然。

swiftなんか業務で使ったらそれこそゴミだろ

日本人特有の「右向け右、左向け左」だよ。
こんなクソ言語誰が使うんだよ？

ここって質問OKですか？

>>129
Apple社員だったら笑えないよなw
>>133
もう言語云々の時代は終わったよね

とりあえずAppleは方向を間違えている
xcodeのやるべき事はスケルトンコードを充実させること、コードの書き方を縛ること
テーブル配置したらデータソースを定義させるとか、各デリゲートメソッドのサンプルをこれでもか！ってくらいデフォルトで表示して、ほとんどプログラムレスでフレームワークを使わせる
これに限るだろ

CFStreamCreatePairWithSocketToHostを使って通信書いてるんだがタイムアウト秒数の指定方法を教えてくれ

>>135
IDEが完璧なら言語はどんなクズでもいいってのはAppleらしいな
今時、特定OS, 特定IDEでしか開発出来ないのはどうよ？と思ったけど、Appleなら仕方ないね

Swiftは試験的にOSSで進行してるけど、失敗と諦めて撤退したら、OS, IDE縛りは再開するかもな

swiftはウンコ言語
ファイルサイズが超でかくなる

アンチスレ一名様ご案内〜

>>139
常駐監視員さん、今日もお務めご苦労様です

ゴミはゴミ箱へ、アンチはアンチスレへ

>>141
まずお前がゴミ箱に入ったほうがいいんじゃね？

>>137
swiftはxcodeがないとまともにコーディングできませんね。
多分失敗ですねコレは。

>>141
お前がいちばん要らないってことに早く気づけよ。

つ AppCode

Vimでおk

氏ねクソ言語

emacs「俺もいる」

Swift3の後ってなにか大きな変更あったっけ？
Swift3あたりで安定しそうならそろそろSwift始めてみようかな。

さっさと始めろ

Swift 5.0くらいから始めても遅くない
あるいはobj-cで申請うけつけないぞ！
になってからがベストなタイミング

そんなC++のライブラリ全滅なことされたら相当プラットフォームとして終わりだな

どーせ無職がお遊びでプログラミングやってんだろ？
いつ始めても一緒じゃん

でもアマゾンのランキング見るとswift関連が上位独占してるよね。

仕事の本より趣味の本の方が売れるからな

もうobj-Cの本は新しいの出てないからな

もうC#で作る時代になったわ

【速報】Xamarin のこれからについて！ - Xamarin 日本語情報
http://ytabuchi.hatenablog.com/entry/ms-xamarin

>>148
3がfixしてないのに何を期待してるんだ
取り合えず3.0の out of scope が更新予定だろ

言語なんかどうでもいいよ。
経済効果狙ってるやつらに踊らされるな

Sygwin終了
MACよりも､WINの方に需要が移るぞ

>>159
日本語でおk

アンチの正体はxamarin日本代理店の社員だったのか

swiftってobj-c から cを抜いたってあるけど
c ― って言語あるのな。ググリビティが低すぎて検索シンドいけど

>>162
どうやって検索すんの？ｗ
気になるが出てくる気配がないw

>>163
c minus minus

>>164
thx

本当にいいもので変える合理的な理由があればこんなにアンチは出てこない
そういうことだ

キリッ

Appleも$wift・・ついに守銭奴か・・

関数型プログラミング的にはSwift結構いいんでない？
あとReactiveなんちゃらとか

プログラミングできる人ってすごいなぁ

JavaScriptプログラマは入りやすいよな
関数ブロックとか、型推論による省略とか、Obj-Cよりはそれっぽい
Reactiveやらプロトコル指向の流行り物フレームワークはUIKitとの相性が微妙？
UIとロジックを分離して設計したら不便ないのかな、教えてエロイ人

>>171
Reactiveのいいところって関数型プログラミングっぽくなることかメリット
つまりただのパイプを量産するのでテストは楽そう。
でもそれを使って綺麗に実装できるかというと
ViewControllerが邪魔な気がする。
状態を持たない作りをするんだけどViewControllerの存在自体
画面遷移を概念化したものだからReactiveXXに取っては邪魔。

そうだよなぁ、、、
FBのReactive.js, NativeはUI含めてReactiveフレームワークを構成してるけど
ViewController的な存在は許してなかったものな

Qiitaで流行り物に食い付いてるヤツラが
そこの誤りに気付いてUIフレームワークを作るまでSwift Reactiveは待ちかのう

$wiftにするとカネ儲かるのか？
Reactiveとかもカネ儲かるのか？

objective-Cに不満でもあるなら

>>174
ディスり芸に熱心だからマジレスすると
保守派を説得するという業務にお金出す人がいるので、お前みたいなヤツがいると儲かる
Obj-CでもSwiftでもどっちでもいい、と言われると儲からない

だからアンチを黙らせたいなら、Swiftに変える逼迫的かつ合理的な理由を示せばいいだけだろ
全然難しくなくね？

ディスり芸してるのはアンチじゃなく愉快犯なんだけどな
より実のない>>177はマジ者のアンチっぽいけど

状態を持たないプログラムって、例えばどんなの？

純粋関数型のHaskellが分かりやすい
ブロック内でしか変数を扱えないから状態を持たない(持てない)
最近使ってる人少ないかもだけど、Emacs Lispもそうだっけか

>>173
ReactiveNativeに走るっというのもありかと。
まだまともに動いてないけどmacアプリも作れるっぽい

>>180
pureScriptつかってReactiveNativeとか出来たらいいのかね

単に状態は引数で渡すというだけのこと

画面は状態を維持するし、シリアライズするモデルも状態を保持する必要があるから、
全体を関数型で構築するのは無理ということだね。

>>184
そういう状態を全部引数で渡す関数として書けるように考えられたのが
純粋関数型プログラミング言語です
引数で渡す関数として書くということを意識する必要を省くためにモナドとかを使います
Haskellとか

>>185
ユーザーの入力を変数に保持する必要があるでしょう。

>>186
ユーザの入力を処理する関数を返す関数を実装すれば、その状態すらも引数です

空中戦を繰り広げてるけど、実際に純粋関数型でUIアプリ作ってみると良いよ

言語仕様としては状態を持つオブジェクトは許さないけど
実際問題として状態を持たないと成り立たないから状態保持を実現するって
若干矛盾したモノを作ることになる

簡単に考えるのならば
ユーザの入力等のイベントと現在の状態を引数に新しい状態を返す関数を実装します
その関数を繰り返し呼べばいいのです

>>189
なるほどね、画面更新のたびにその関数を呼んで全ピクセル計算するわけだw

Reactive.jsとかReactiveNativeとか言ってるやつら、名前からして間違ってて知ったか丸出しでウケる

今なら箸が転がっても笑ってくれそう

React Native(js) vs Swift なら Swift の方が使いやすいと思う
フレームワークとしてはキレイだけど、Reactは色々と理想を追い求めすぎてんよ、、、

>>190
vdomとか知らなそう

>>190
全部計算して新しい状態を作り直す必要は無いのです
入力等のイベントの影響をうける部分だけを作り直して、
変化の無い部分は古い状態への参照でいいのです
場合によっては古い状態をまるごと新しい状態として返すのもありです
これを実現するために重要なのが不変オブジェクトであり、
オブジェクトが不変であるからコピーでは無く参照を使って
上記を効率良く実現します

ObjC擁護してSwift叩いてる層は、単に新しい技術やパラダイムを知らない、知ろうとしてないだけ？

AppKitでもUIKitでもなんでもいいけど、
Swift NativeのUIフレームワークがない限り、
import Cocoaはほぼ必須ですよね。

どんなにSwift推しでも、UIはCocoaに頼る必要がある以上、
純粋なSwiftオブジェクトより、NSObjectのサブクラスを
結局使っちゃうけどなぁ。

>>192
それにXamrinも足してバトルしてほしい。
果たしてどれがいいのか。
windowsPhoneの将来に期待が持てるようになったら
c#という選択肢もありなのかもとはいえc#の魅力は全く知らないんだけど

おれの場合Windows業務系の開発が仕事の主体だし
こんな状況になったらもうC#一択かな

叩いてる人の具体的な意見としてはどういうのがあるんだっけ？
iOSアプリ開発が中心の人ならともかく、たまに開発するくらいの頻度だと、
必要になるまで積極的にSwiftを勉強しない、なぜならObj-Cで同じことできるから様子見、ってのは叩くのとは違うよね？

>>197
ファイッ
Lua: Corona
Python: Kivy
Ruby: RubyMotion
C/C++: Cocos2dx
C#: Xamarin
Java: RoboVM
HTML5/JS: Cordova
JS: React Native
Any: Unity

こんなもの、どれでもいいレベル、軽いアプリケーションを作るなら得意な言語で作れば良い
どうせUnity(ゲーム)以外で１言語マルチプラットフォームは汎用的な商用開発に耐えない

RubyMotionとかあったなぁ、あれこそ完全にオワコンだな

デスクトップだとElectron製アプリが爆発的に増えてるけどね

C#は開発効率良いよなぁ
linqとwpfはすごいわ
どっちも開発に使ってるけどswiftはまだ泥臭いコード書かされるところ多い

>>203
もうちっと具体的にC#のメリットをswiftと比較して語ってくれると嬉しい。

>>194
それ状態を保持してるじゃん。＞古い状態

Swiftの勉強したくないからSwiftアンチしてると思ってるバカが多すぎ

>>205
だれが古い状態を保持しているのですか？

>>207
は？
保持して無いなら何を参照してるんだよ。

根本的に関数型プログラミングをわかってなさそうだな

他人の書いた$wiftコードは読めない

>>206
swiftで仕事してるが型推論で楽々なswiftがクソすぎ
その時楽したペナルティーが大きすぎる
optionalはプロとビギナーで使い方が違いすぎてカオスになるし
えっクソコードの無駄な頑張りも痛い

>>206
お前は勉強しても理解できないだけだもんな

2年も前からswift使うとobjcより生産性低くて工数かかるって言われてるのに
今さらObj-Cマンセーを担いでアンチするのは理解に苦しむ

こちとら、それを承知で使ってるんだよ
アンチやヘイトしてる信者は何を期待してるんだろうね
swiftが害悪だからやめろってのは、PGじゃなくPMに言うべきことだろ

>>208
状態の一部分もしくは全体を参照しているのは、引数もしくは戻り値です

>>212
そういう思い込みもバカ丸出しだな
Objective-CができてSwiftが理解できないやつなんていないだろ

Optionalやfor eachは理解出来ても使いこなせない子がいるらしいっすよ？
あと、インクリメントは分かるけど、デクリメントが分からない>>62とか
新しいことを使いこなせないと大変だなぁ

ちょっとXamarinをきっかけにC#もみてるんだけどoptional型あるんだね。
https://ja.wikipedia.org/wiki/C_Sharp
ちょっとやってみたくなってきた。
C#は歴史がそれなりにあるから言語仕様的に割と安定してるのかな。
マルチプラットフォームで開発できるのは魅力的だなぁ
ビジネスロジックをandroidとiosで共有化できるし

typeScriptといいVSCといいマイクロソフトの開発環境の開発力は高い気がする。
いっその事ios開発環境をマイクロソフトが作って欲しい

>>215
いや、直近のスレの流れを見てるといるみたいだぞw

>>218
もしそれが本当ならなおさらSwiftの利点がなくね？

>>219
どゆこと？
Swiftに限らず、何かの利点とそれを理解できない人がいることは関係あるのかな

質問です。
NSStringとStringの相互変換
NSArrayとArrayの相互変換
これらのオーバーヘッドとか、ガイドラインとか、
まとめられたページを探しています。

前者は必ず成功すると理解しているけど、オーバーヘッドは無視出来るのか？
後者は参照型との変換が都度発生するので極力変換を避ける、と理解していれば良いですか？

それくらい自分でベンチマーク作れと言いたいが
http://pastebin.com/GVGL446t

% swiftc bench.swift
% ./bench
Array to NSArray: 196.956992149353 msec
Array to Array: 2.87497043609619 msec
NSArray to Array: 547.742962837219 msec
NSArray to NSArray: 0.0150203704833984 msec

なんかNSArray to Arrayが異常なのでキャストの仕方で良い方法をエロい人教えて
あと、要素の型がClass, Struct, プリミティブ型でも違う気がするからそれは自分でやれ

25行目にdateの更新抜けてた、脳内補完でよろ
結果は誤差かのう
Array to NSArray: 195.33497095108 msec
Array to Array: 2.90495157241821 msec
NSArray to Array: 531.825959682465 msec
NSArray to NSArray: 0.0210404396057129 msec

NSArray→Arrayは型チェックでO(n)かかる
ObjCの方でジェネリクス指定してる場合どうなるかは知らん

NSArrayで<Int>で指定しようとしたら当然ながらビルドエラーだったよ:(
その辺りも暗黙の型変換入ってるから、NSObjectを要素にした方が正確かもしれん

NSObjectにしたらNSArray to Arrayも耐えられる速度になったので、ループ回数の補正も直したよ
http://pastebin.com/3NvM9xES

Array to NSArray: 193.588972091675 msec
Array to Array: 3.18503379821777 msec
NSArray to Array: 209.782004356384 msec
NSArray to NSArray: 3.2770037651062 msec

要素がIntでクッソ重いのはプリミティブ型だと型チェックに加えてコピーしてるんじゃないのかねぇ
NSArray to Array が Array to NSArray の 2,000倍 遅いのは条件分岐ってレベルじゃない

NSArray to Arrayは構造体に中身詰めなおしてるけど、
Array to NSArrayはSwift Arrayをヒープに移動させて、参照保持してるだけなんじゃないの

それだけなら>>226で同等性能な説明がつかなくないか

最新のObj-C仕様を知らないが、今もNSArrayにプリミティブ型突っ込めないよな？
Array<Int> => NSArray<NSNumber> で全要素分のNSNumberインスタンスを作ってるんじゃないか
それなら要素がIntの Array to NSArray だけ極端に遅い理由は分かる

まぁ暗黙の型変換はアポーの御心によってちょいちょい動作変わるから、理解するより慣れろで使うべきだと思う

The Swift Array Design
https://github.com/apple/swift/blob/master/docs/Arrays.rst

まさか早い早いと言っていたSwiftが遅かったとはな、、残念だ

これ要は、普通にArray<object>使うと代入直後は値型じゃなくて参照型になるって言ってるかな？

ObjectでなくSwift側がprimitiveである場合、変換で都度全要素のCastが動くから重い。
CopyーOnーWriteなので、更新がかかったらその場でコピー、値型として振舞う。

その場合メモリ断片化し得ると読んだけど、cast直後と、その後Arrayの要素を操作した後とで、パフォーマンスに差が出そう。

ネイティブアプリのメモリの断片化なんてH/Wの仕事だから、そこがモッサリjavaとの大きな違い

Arrayは参照渡しなだけでバッファはヒープにあるだろ

obj-Cのほうが単純で分かりやすいよな

SwiftのArrayも、要素の追加削除ができる時点で、内部的にはポインタで管理だな。

メモリ断片化排除ってhwの仕事だったの！？

ネイティブアプリはそうだよMMUの仕事
javaはVMがシコシコやってる

VMがMMUに処理を渡してる、とマジレス
VMもネイティブバイナリだから当然だよなぁ

>>230
速いって思ってるのはエアプログラマだろw
実用してるヤツラでもswiftの性能の悪さは周知の事実だ
それを補うメリットがある(？)から使ってんだろ

>>235
let Arrayとvar Arrayで中の人が違う、、、と思いたい
NSArrayとNSMutableArrayも違うよな、そうだよいってくよ、バーニィ

Swiftに変える合理的な理由などない
Appleが変えたいから
それ以外に理由などない
AppStoreでおこぼれもらいたい下僕どもはただただ従うのみ
以上だ

>>240
>>167

ちょっと誰か教えてください

for var i = 0; i < 100; i += 5 {
//
}

みたいなforを書いたとき

C-style for statement is deprecated and will be removed in a future version of Swift

って将来のことをいわれ、書き換えようかとおもうのですが、こういうパターンのときってどうしたらいいんですか？

あ、、ポイントは i += 5なところです。。 i += 1 なら 0...100 やりゃいいんで困らないのですが。。

すみません。 >>66 に答えがありました。。。

0.stride(through: 100, by: 5).forEach はどうよ、と思ったら遅せぇww
http://swiftlang.ng.bluemix.net/#/repl/40ddd8e51fed22e0f73f04401e36f7448a559376ab0455580d3691e515d7de2f

$0も可読性悪いし、Map forEachはないわな
この程度は誤差だけど、可読性無視したにわかが好んで使いそうなので
その場合は生暖かい目で見てあげるのが正しい処置なんだろうな

その書き方するぐらいならwhile使えよ

アンチがフィーバーする前にも言われてたけど
for each入れるのは良いけどC style forを削除するのはアホだよなぁ
proposalではC style forとstrideが等価機能って言ってるけど、性能まではそうではない

アンチCありきの言語なんだから仕方ないだろ
諦めろ

swift まだまだ言語仕様変更たくさん入りそうで、大量のコード書くのが怖いや(;^ω^)

性能より間違いの無さなんだろうね
レベルの低いプログラマでも安全なコードになる様、自由に書けないように設計されてる気がする

>>250
>レベルの低いプログラマでも安全なコードになる様、自由に書けないように設計されてる気がする
もし本当にそうならまずARCをやめるべきだろ。
単純にobj-c依存ライブラリが大半な過渡期であり、
性能よりモダンな書き方と依存ライブラリとの極力シームレスな接続を目指したってところ。
そのうちswiftで書きなおされた新UIKitがswiftで書かれてきて
それをobj-cから無理やり使えるという逆転状態に持って行くと思う。
そうやって少しずつ移行を進めていく。
いままでのAppleのやり方ってそうだったし。

>>245
lazy 噛ませてリリースビルド(-O)でコンパイルすれば
lazy-stride + forEach と stride + for-in と C-style for文 は同等の速さだったぞ

lazyとかwww
いまはLOUDNESSやろ

>>250
バカ用言語Swift ｗｗｗｗｗｗｗｗｗｗｗｗ

自由度高杉で$wiftが嫌いなんだが・・

lazyとかのコンパイラマジックをあてにしてると痛い目に会う

lazyがコンパイラマジックとかwww

>>247
性能はどう頑張ってもCと等価にはならんよ。
>>229にも等価がゴールだと書いてるが、ランタイムで関数呼んでる時点でオーバーヘッドがある。
Appleは低レベル用のCのAPIも整備してるので、使い分けだよ。

>>258
それは承知だけど、C style forは勿体ないなぁ、、、と
for I in 0...100 で1づつ上げるなら同等だったけどさ

ついでに ++ と advancedBy の性能評価したら、こっちは同等だった
Obj-Cも SwiftもどうせIDEなしじゃ辛い言語なので、コーティングの面倒は無視しよう

>>238
VMか使うメモリとアプリが使うメモリは違う
アプリが使うメモリはVMが管理する必要がある
MMUの手助けは多少あるかもしれないがVMからMMUは見えないから

今更swift覚えるヒマがあったらframework3つ覚えたほうがいいよ

もう言語レベルの未来はC#かjavaでいいよ。。

意識高い系は車輪の再発明って言葉好きだけど
そういう奴に限ってこういうの好きなんだよな

何十年前のVM実装を想定してるんだ、、、
AndroidはJava、JavaだからVM、VMだからMMUは見えない
よって、 AndroidはMMU見えてない、みたいな短絡理解すらありそう

OSやランタイム、コンパイラ特性を個々に詳しくないけど、厳密に管理したいって人はC/C++安定だな
Obj-Cも大概特異なコードだけど、それに輪をかけるSwiftは全く向かない
意識高く無駄に気を回して、逆に性能悪いコード書きそうだよ

AndroidはLinux KernelつまりC/C++じゃんか

論点ズラしか、マジレスか、ネタか分からんが、ちょっとワロタw
C#のダイレクトマーケティングより、そのお笑いを活かして欲しい

>>252
うろ覚えの範囲で構わないのでサンプルコードplz
lazy周りの有効な使い方が知りたいよ

C#って、最近はCホンハイって呼ばれてるんだろ。
恥ずかしくて使いたくないよ。

$wiftも恥ずかしい

潰れたシャープって全てがシャープじゃなかったな・・
東芝も間もなく倒産だし・・

XCode7.3にしたらSwift、iOS7でBad Accessするようになったんだが、早くなんとかしろよ。
というか早く開発のサポート打ち切り宣言してくれよ。

class A<T> {
var hoge: Int
init() { self.hoge = 1 }
}
class ViewController: UIViewController {
override func viewDidLoad() {
super.viewDidLoad()
let _ = A<Double>() // ← 死亡
}
}

>>271
どうした？泣き言か？

落ちるのは問題でしょ
こういう問題ってOSバージョンアップした時に起きたりするの？

なんでクソなSwiftなんか使ってんだよ
自業自得
もっと完成度が上がってからにすればいいのに

これマジすか？

Google、Android用開発言語として
「Swift」への移行を検討中か？！
http://gori.me/google/google-news/85695

ステマ乙
Xamarinくらいのダイレクトマーケティングでやり直し

もしGoogleが開発に加わったらかつてのWebKitみたいに開発改良が加速するだろうな

ORACLEにネチネチ金を毟り取られるのに嫌気がさしたんだろう

スレチだけど、Oracle(Sun Microsystems)に対しては不誠実すぎるからむしられてまえと思う
Java仕様策定グループに入って数年後、自前のJavaVM実装作ってAndroidとかOracleはキレていい

DartやGoもモバイル向けじゃないし、永遠むしられろ
ART Runtimeごときで逃げられると思うなよ

swiftでandroid使えるようにするくらいなら
googleが正式にkotlinをメイン言語に据えるって発表したほうがいいのでは？

AppleもGoogleもSwiftへの「移行」ってのが馬鹿だよなあ
なんでMSみたいにユーザーが言語選べるようにしないんだ

本来なら一本化する方がいいに決まってる

WWDCまであと二ヶ月しか無いけどSwift関連ではバージョン3意外に何かアナウンスできるものがあるんだろうか
中の人の進捗どうなんだろ

>>282
それは開発者の都合であり
エコシステム作ってる側からすれば　囲い込みたい

>>282
objcとswiftはダメだと

Swiftの覇権確定したな

>>272
泣き言だよﾊﾞｶﾔﾛｰ

>>273
swift2.2対応かね？

>>274
Xcode7.2まで問題なかったが完成度あげられたせいで発生した問題ですが？
ていうかいつまでもObjCとか使ってられねーよ。
Appleがいつ打ち切るかなんてわかったもんじゃねーし。

UIColorにextensionでFailable Initializerを追加してんだけどreturn nilする場合は先にself.init()しないとBAD ACCESSで落ちるようになったわ
2.2からは早期に打ち切れるようになったんじゃないのかよｗ

継承とextensionは実装が別物じゃないの？
と思うけど、切り分け理解出来ない子が多そうだから
super.init()の後呼びなんて非対応のままにしておけば良いのにな

実は2.1までextensionでself.init()呼ばなくても通ったんだよ

>>274
アンチスレ行こうぜ
ここはswiftがお似合いの人種のスレだ

みんな色んな人間の反応が見たくて集まってるわけだからアンチスレへの隔離は意味ないよ。
アンチの書き込みも信者の書き込みもきちんと真摯に受け止めるくらいじゃないと。
信者同士の馴れ合いがしたいんならFacebookのほうがいいね！

いや、生産性のないヘイトだけのアンチはアンチスレにどうぞ
ダメな所を指摘するんじゃなくて、ディスリ芸だったりObj-Cマンセーだったり、前スレ酷かったからな

Swiftマンセーも酷いけどな

ObjCが良かろうが悪かろうが、Apple様がSwiftに力入れる（そのうちObjCは切るかもしれない）って言ってんだからついていくしかないだろうが。

しかないって、依存度100%だな

マジモンのswift信者は前スレ、今スレにはいないと思うがなぁ

Obj-Cを切るかもという噂もあるが
SwiftはそのうちIBMに押し付けてアポーはフェードアウトする可能性もある
どうせApple OS専用言語なので依存するのは良いが、Obj-Cと両睨みでやってないと恐い

アンチはアンチなりにもっと具体的に問題点を指摘してくれたほうが
意味があるからなんとなくのアンチはやめて欲しいところ。

obj-cもcのライブラリとか使いたい時にはありがたい。
c++のライブラリもNSDictionaryとかNSArrayを使ってラッパーを作って
swiftから使うという使い方が便利。

だからobj-cもずっと残って欲しい。swiftからcのライブラリを使うのはつらすぎる。
俺にとっては住み分けの問題でどっちも必要なんだよね。

でビジネスロジックはswiftを使いたいかな。

>>295 >>297
>Apple様がSwiftに力入れる（そのうちObjCは切るかもしれない）って言ってんだから
>Obj-Cを切るかもという噂もあるが

初耳詳細希望

$wiftがいいとか悪いとか嫌とかなのではなくて、同じ結果を出すのに、なんで新しい言語を覚えなきゃならないのかってこと
obj-Cで十分まともなプロダクトになる

ObjCなんか切るに決まってんだろ
今年のWWDCでObjCの葬式やるよ

なんかすげえことになったな
去年くらいにswiftやったほうがいいことになる
とかまとめサイトにまとめられてたやつがいたが
このことだったのか…

JavaScriptに文法似せてその層のプログラマを新規参入させるのが目的で、現行Obj-Cやってる層はそのままで良い
というのに、何故か、排斥される！と危機感？を感じてディスりに来るObj-C信者がいるのがオカシイ

>>299
眉唾情報をフィルタ出来る人でないと(掲示板を使うのは)難しい

>>290
self.initなしで動いてたのは驚きだw
なんか突貫で直した感じだから、そのうちまた改修入りそうね

>>300
むしろ新しい言語覚えるのそんなに大変じゃないだろ
UIKitの使い方は一緒だし

>>303
JavaScriptしか書けない人間ってあまりいないかも知れないが、純JavaScripterがSwiftをやったら型とオプショナルでつまずきそうな気がする

将来はobjc切るかもしれないけど、数年はないでしょう。
それなりにば言語として落ち着いたらobjcに対する新機能実装は減っていき、swift優先で実装されるんだろうけど。
いそれなりに言語として普及してアプリが出た状態にならないと
iOS/Macのアプリ開発者が減ってアプリ販売本数が減ってアップル収益を崩しかねない。
5年以上は両方続くと思うなあ。

AppleのOSの開発に限ったとしても
現時点では魅力のない言語だと思うよ
AppleのOSの開発だけで満足する人で既存の言語を知らない人がするにはいいかも知れないけど
将来性がまた見えてないしリスクがあることは承知してやるべきだ。
WindowsやLinuxやモバイルまでも考えているなら、こんなもの論外だということは認めてからやろう。

そんな分かりきったことをドヤ顔で言わなくてもw

>>305
型はJSでも少なからず意識するし大丈夫じゃない？
コンパイル時にエラー出す分、楽な気がする

オプショナルは、、、評判悪いのう
慣れると別に大したモノじゃないけど、最初のナニコレ！？感をよく聞くわ

Swiftのターゲットの範囲ではObj-Cより書きやすく、読みやすくなるのは事実だと思うし、Swiftの存在価値がないとは思わない。
一方で、SwiftがObj-Cを全て代替できるわけではないのだから、Obj-Cで書いたほうが明らかに楽な部分があるのもまた事実。

Swiftなんて消えてなくなる、Obj-Cなんて消えてなくなる、のどちらでも、言ってる人は業務範囲が狭くて羨ましい。
Obj-C++が使えなくなって、C++のライブラリ使うのにラッパーのCライブラリを書いて呼び出すなんてのは本当に勘弁してほしい。

Swiftが使われるようになるって聞いたけど
勉強は難しいか？

ですか？

Swiftの言語仕様自体は別に難しくないけど
結局標準的なパターンみたいなものがなくて、
「これがSwift流だ！」って言ってるやつがみんな自己流オナコード見せ付けてくるから、
真面目に業務に利用する言語として勉強するのは難しいと思う

逆に分からんやつしかおらんから、オナコード書いてSwift使えるって詐称するのは簡単

新しいパターンとかは無いもんな。

新しいパターンもクソもないだろ
素人ほど意味不明なこと言いだすよね

Swift終わったな・・

もうアセンブラでいいよ

オレに聞け！スレがたたない限り無理

>>315
このレス懐かしいなw
久しぶりに見た気がする

>>303
いや排斥予定なんだろ？
じゃなかったらこんなアンチがわくわけがない

>>280
kotolin悪くない、っていうかjavaより断然いい、があれはあくまでjvmありきだから。

obj-c->むかつく->会社の子のおっぱいでも眺める->落ち着く->obj-c->むかつく->おっぱい->落ち着く->完成！

あの子のおっぱい! →nilでエラー
学んだ事：ブラをunwrapしてはいけない

>>322
ブラはOptional型じゃないだろ。

あの子のおっぱい? →nil
貧乳でもエラーにならない

>>322
いくらなんでもnilはないだろ

SyaseiとかMankoって名前の言語名だったら引くよな

ヌーブラunwrapするときやけに萌えない？

>>327
見たことないくせに。DT。

最近またswift使い始めたけどプロトコル指向って要するにどういうこと？
どんな感じの図式になるのか想像できなくて書き始められんのだけど。
クラス使わないって訳ではないんでしょ？

protocolにextentionで実装持たせられるってのはPlaygroundで出来たけど
これ変数の格納はできないじゃん？そこはクラスでやんの？

そういう流行りモノはQiitaに行った方がいい
ここですらReactive、関数型、プロトコル指向、etc.、一年単位の流行りは追ってない

そういう意識高い系用語は気にしなくていいです

Qiitaどころかググっても分かりやすい説明ないんだよねー
単に翻訳したやつを上っ面だけ紹介してるような。
まあ2.0でそういうことも出来るようになったよ的な感覚でとらえとくわ

Reactive・・・古いCocoaプログラマなら「Cocoa bindingがやっと時代に追いついたか」という感想しか持たない
　　　　　　　　そうでもなくても、Observerパターンの発展系でしかないので、デザパタをちゃんと理解できている人なら新しくもなんともない
関数型・・・ガチな純粋関数型言語をやりたければHaskellでもやればいいと思うけど、数学の問題解くのにしか使えないよ？
　　　　　　　第一級関数の性質があればいいだけなら、blocks導入の時点で実現されていたから今更
プロトコル指向・・・インターフェース指向の言い換えでしかない上、今のオブジェクト指向では当たり前すぎる考え方

用語を変えて新しい概念と吹聴するのはやめよう

>>334 に大筋同意だけど、ちょっとずつ改良が加えられてる印象かな
objc派には改悪かもしれないけど

Qiitaとか業界の癌だよ
もう新しいもの要らない

プロトコル指向は、実装ベースの継承じゃなくてインターフェースをベースにしたクラス設計をしなさいってこと。
Swift においてはプロトコル拡張を使うと特に便利になるよ、程度のこと。
protocol oriented programming definition
で調べてみたらいい。日本に紹介されてるレベルと大差ない。Java などの例も載っている程度。
dependency injection とかアスペクト指向なんかもプロトコル指向の上にあると言える。
難しく考える必要はない。


またobjcがなくなるなんて話が出てたが無知の証。
Cocoaを使うためのobjcでありSwiftであって、フレームワークを書き直すまで捨てられることはない。NSが何の略だか知りもしないのだろう。
性能が必要な部分をc/c++で書くならSwiftよりもずっといいだろう。Adobeやゲーム屋を追い出すとでも思うのか？
Macの歴史は過去切り捨ての歴史でもあり、もちろんCocoaを捨てることも十分ありうるが、その時はSwiftも一緒にポイだろう。


> 数学の問題解くのにしか使えないよ？
アホか。

泥にこれ使うらしいから学ぼうかと思うんだけどおすすめの参考書とかある？

linux環境しかないけど無理かな？

Swiftは必ず死ぬからやめておけ

xcodeが静的解析するなら新言語とか要らないからframeworkの使い方のミスを解析してくれ、昨今の開発って単機能はリファレンス見れば分かるんだけど、APIとか含めて流れを作ると思い通り動かない。サンプルみたいに単純なアプリないし。

>>338
幾つか本買ったけど正直ググるだけで解決する

むしろ更新の早い新興言語で書籍買うのは悪手
公式マニュアルを一通り読むだけの方が要らぬ癖つかなくて良いと思う

>>342
要らぬ癖はよく分かる
まだスタンダードが定着してないからかオレオレな感じの書き方してる解説が多い

てかプロトコル継承した時点で自動的に実装が必要なもの書き出してほしいわ
その方が単に英語でエラー吐くだけよりいい

overrideが必要なinitも自動でスタブ生成してほしいな

Swift使ってもなにも楽にならない
のはなぜ？

アンチスレへ一名様ご案内ー

>>346
楽云々よりヌルポで死ななくなるやん。真面目に書いてれば。

>>346
ObjCでチャランポランな糞コード書いてたからじゃね？

SwiftをAndroidで動かしたアホがいるのなww
http://romain.goyet.com/articles/running_swift_code_on_android/

>>344
この辺はobj-cがまだ優位かな。
swiftの各種支援機能をxcodeに実装して欲しいけど
リファクタリングすらついてないからね。
xcode自体歴史が長いからそろそろコードを一から描き直さないと
swift対応できないのかもね。それともApple自体が
swiftの言語仕様大改変が今後も続くことを想定してxocde側の実装を避けてるのかな。

>>334
Reactiveの項目に関してはちょっと補足がある気がする。

RxSwiftとかReactiveCocoaとかの話だと思うんだけど
イベントの発生源を起点とした無限長のストリームという
共通のインターフェースを提供する機能だと思う。
NotificationとかKVOとかを統一したインターフェースで扱えるのがメリット。
でもそれだけじゃ見通しの良いコードにはならない癖にわりと
学習コストがかかるのがちょっと残念な感じなんだよね。

>>351
>この辺はobj-cがまだ優位かな。
何言ってんだ
protocolのスタブ生成してくれないのはObjCでもずっとそうだろ
Visual StudioでもEclipseでも当たり前の機能なのに

IDEスレや意識高い系用語定義スレで議論していいのよ

swiftダメだな

objcもダメだな

オレダメだな

>>357
それは誰も否定はしない

d

>>347
常駐さんなんですか？

お兄ちゃんたち！
助けて欲しいんだけど、、、、、
xcodeでiphone用のipaファイルを作りたいんだ！
でも、開発者アカウントを持ってないから普通にエクスポートはできないんだ。
でもでも、以前に作ったAppのipaファイルはなぜかPC上にあるんだよ！
Ad-Hocかかってるみたいだけど、どうやったのかな。。。。笑
ググっても分かんないんだ！！
どなたか教えてください。お願いします。

swiftで長時間コード書いてると時々xcodeが狂ったように候補出してこない
もう無理

IDEに頼るな
昔はおまじないすら暗記してたじゃねーか

>>361
http://potato.2ch.net/test/read.cgi/mac/1447650023/

xcodeがクソかswiftがクソか分からんが、
おれもサクサク感ゼロのxcodeにキレた。
おまけに正しいのにエラーが消えずにレインボー5分間とか氏ねと言いたい。
つーか、objcで必要十分。

Googleがswiftに色目使い出したからそろそろ覚えようかなって

アンチはXcodeに不満をぶつけ
煽りはGoogleがSwift採用とはやしたてる

まとめてアンチスレへ

信者は(ry

俺が信者ならGoogleがSwift採用！ObjC終わった！！と煽りに乗ってるわw

swiftの？！だらけのクソ言語のつまらなさと言ったら、もう、、

手垢のついたOptionalヘイトはアンチスレへ

毎日アンチスレへの誘導ご苦労様です。

>>353
warningマークをクリックしてみ
自動生成されるから

>>373
されねぇよ
嘘をつくな

requireならwarningに出るだろ。

プロトコルの実装は出ないだろ

require init はwarningから出た気がするな
プロトコルはescから選択しないと書き出されない

過疎ってるな〜swiftダメかな
でもコレSUZUKI自動車の登録商標じゃね？
またスイーフトとかって発音するの？

いつも九州の後は東京
ガクブル

ReSwift使ってる人いたらどういうものか説明頼む。
ViewController普通に使うの？

UIApplicationはUIWindowを持ち、UIWindowはrootViewControllerを持ちます。

Protocolなんてただのデザインパターン
ただの関数ポインタ
新しくも何にもない
swiftなんかクソ

しかし世界的にAppleひとり勝ちでAndroidスマホが死亡寸前なんだよな・・困った・・

世界的にはiPhoneのシェアがジリジリ減ってるんじゃなかったっけ？
日本も奨励金廃止でiPhoneピンチだし

>>383
何言ってんだこいつ

iPhone SEの登場で世界的にもiPhoneだらけになる

Androidは産業機器で生き残れるか・・
Appleがその分野に興味を持ったらアウトかな・・

こういうApple信者がAppleの出したSwiftを認めないのはヤバいなぁと思う
今後Appleが出す新しいモノ、盲目的に素晴らしいって言ってくれなくなるんだものな

SEは見事に5cの二の舞を演じてるようだが

Appleはオワコン
時代はswift

swiftだけはない
？！だらけで書いてて楽しくない

nilが問題なのではなく
「nilは大問題だ！！！」
と騒いで業界を掻きまわしてる奴らが問題
そんなつまらん洗脳にひっかかるな！
ジョブズが愛したobj-cでコツコツやろう

ビックリしたり疑問を感じたりかわいいやつだな

swiftオワコン！

「おれ、Obj-Cは分かりませんが、Swift分かります(キリ！」

オワランじゃないのかｗ

オマエバカジャナイノ？

何だか最近盛り上がってないね。書き込みも少ない。
WWDCの頃には活発になるかな。

これでもム板勢いトップ5やぞ
ム板に人居ないだけ
っていうか2ch自体がオワコンなだけ

勢い順にスレを見てみたけど上3つは凄い書き込みあるね。4位のこのスレ以下がオワコンって事なのか。

上3つも有用な書き込みなんかほとんどないぞ

>>396
「なるほど。ところで君C言語くらいはできるよね？」

c言語の賢者様に聞きたいんだが「」は何の意味があるの？

面接官と受験者のやり取りと見た

AndroidのためにJavaを覚えるとStrutsのシステム保守に回されるし、
iOSのためにObj-Cを覚えると謎のグローバル変数で奇跡的に動作している組み込みの世界に送られる

Swiftやればいいじゃん
炎上が約束されたiOS PJに回されるよ

SwiftはC++ライブラリ使えないのがほんまゴミ

知らんけどC++ぐらい使えるんじゃないのか？

>>408
Obj-C++でラッパークラス書かないといけない

swift swift って、無視、無視
絶対に騙されないぞ！！！

Swift信者って自民党みたい
信用して頑張っても老後破産だし

AppleはタイミングをみてSwiftをIBMに手放すんじゃないか？
盛り上げゴリ押しがキモい。
unwrapなんかプロには不要だし。面倒くさいだけ。
やっぱりC#かな・・

最近感動した事

プロスポーツにお金を払ってはいけない

Appleにお金を払ってはいけない

いい加減実行時エラーの場所をピンポイントで教えろやボケ

>>407
つ swiftpp

>>414
Xcodeで実行時にちゃんとピンポイントで止まらないか？

AppDelegateまで吹っ飛ぶか妙なtry catchで止まる
相変わらず低レベル

すべてのexceptionを受け取るブレークポイントを設定しておくだけ。
３秒で完了する。

try!を下手に使ってんのかね
もしくはoptionalを適切に使わずobjcならnilで落ちるようなコードか

素直にobjc使った方が幸せそう

https://developer.apple.com/wwdc/
なんというSwift推しデザイン
ObjC廃止発表ありそう

マジで廃止発表があると思っているのなら頭がおかしいとしか

Swiftは信者の存在が邪魔

オブシー信者涙目wwww

objc信者を煽りたい愉快犯だろ
これに食いつくアンチはいない、、、と思いたい
前スレはアホほどいたけど

objc終わるのか
もうおわってたようなもんだったけど、改めてご愁傷さま…

別にobj-c終わらんよ。swiftと競合するものじゃない
すみ分けは可能だし

競合でも住み分けでもなく置き換えなんだよなぁ

置き換えなんかあるわけない。
無知すぎるし頭悪すぎる。

でも、AppleはこれからどんどんSwiftにリソースを割いていくし、逆にObjCはSwiftへの追従程度のメンテナンスモードになることは、ObjC用語してる人も認めるよね？

リソースを割けば良くなるとも普及するとも限らないけれど。

むかし、数年間「これからはJavaだぜ！」ってんで
AppleがCocoa-Javaって環境を用意したことがあって
すぐ「やめます」ってなるんだが、それとおなじ臭いしかしない。

これからはJavaだぜw
あたりはずれもあるさ。

オワジェクティブ・シー

まともにSwiftでコードを書いてたら置き換えどころかObjCの廃止なんて10年単位で無理だと分かるもんだがね。まともに書いてないライトウェイトな考えの奴程Swiftに夢見てるよな。

>>433
今のところオープンソースで存在するSwiftで書かれたライブラリはどれも、ライトウェイトでまともじゃないな感じすか？
それらと比較して、ObjCで書かれたライトウェイトじゃないまともなオープンソースなライブラリって例えばどんなのを指してます？

ライブラリじゃないが
まともじゃないjazzy
まともなappledoc

他に選択肢ないから使うけどクッソウケる実装だったぞ

>>430
MSがJavaVM作って訴訟負けしたからな
OSベンダーによる自前VMは当時許されなかった

>>435 jazzyのどこらへんが、Swiftがライトウェイトでまともじゃないかんじっすか？

jazzy
Ruby 71.1% CSS 18.2% HTML 9.0% JavaScript 1.7%

やっぱりSwiftコードは少ないな！
コード量はさほどではないにしても、enumにメソッド追加しまくりでシネと思う
enumを構造体やクラスとして使ってんじゃねーよ

ObjC:AFNetworking, Swift:Alamofireも結構ひどかった覚えがあるな
まぁ後者は取り敢えず作ってみた、という感じだったので今はマシになっているか廃れているかしてるかもしれんが

防衛線張りまくりのアンチほどカッコ悪いものはないなw

使ってる上で批判は良かろうw
Optionaaaaaalって叫んでるワケでもなし

CocoaPodsでObjC Lib + Swift安定
Carthageも Swift 3.0 の Package Manager で居なくなるかもしれんし、Swift Libなんて使ってるエアプログラマと遊ばせろw

え？ 「まともにSwiftでコードを書いてたら置き換えどころかObjCの廃止なんて10年単位で無理だと分かる」という話の流れから、その例えとして出てきたjazzyが「Rubyで書かれてるライブラリだからダメ」っすか？

それってSwiftとObjCの話じゃないですよね？

>>434
誰がオープンソースライブラリの話してるんだ？
どっからそんな話出てきた

何事もやりすぎたらダメだよ
Swift推しってobj-cで飯食ってるやつらの目くらまし
AppleやSwiftに未来なんかない

>>443
あなたの言う「まともにSwiftでコードを書いてたら置き換えどころかObjCの廃止なんて10年単位で無理だと分かる」を客観的に判断できるものとして、オープンソースのライブラリより適したものがあるなら、それでも構いません。

「俺がSwiftでまともなコードを書けないからダメ」って主張ではないんですよね？

jazzyやAlamofireのSwift部分読めよ
なんでスルーするんだよ, せっかく出してやったのに悲しいじゃないか

>>446
だからjazzyのswift部分ってどこだよw

Swiftで書かれたライブラリの実例としてjazzyが「クッソウケる実装」とか強弁したのに
jazzy実はRuby実装でしたってばれてアンチ顔真っ赤で話題そらしに必死w

えー・・・コードも追えないのかよ・・・

jazzyの中の人な
http://github.com/jpsim/SourceKitten/tree/c4da1e86f441ee9596c441ec3321e5d023beca19/Source/sourcekitten

なんか恥ずかしいSwiftエアプログラマがいるな

>>448
jazzyじゃなくてSourceKittenだろw

>>429
> ObjC用語してる人も認めるよね？
認めるわけないだろ。無知すぎるし頭悪すぎる。
OS や Cocoa 自体を objc じゃなくて Swift で書くってか？
Adobe やゲーム屋が c/c++ を使わなくなるってか？
アホが。

まずはSwiftの処理系をSwiftで書くところからかなｗ

OSの方のSwiftではFoundationがSwiftで書かれてるからって、Foundation以外もObj-CからSwiftに移行中だと思うのは希望的観測すぎるんじゃないかなぁ
それ以外にも実際にMacやiOSのアプリを開発するのに必要なframeworkめちゃくちゃあるでしょ。AppleがSDKで提供してるのも、サードパーティが提供してるのも。

今はiOSアプリのおかげで少なくともインタフェース部はObj-Cで書かれたそれらのライブラリがそれなりの量の資産になってきたのに、Obj-C廃止しますとなったら、
相当にアプリ業界停滞するんじゃないのかなぁ、AppleについてくのバカバカしいからiOS対応やめよう、Webアプリでごまかそうってなるでしょ
せっかくそれなりのユーザ人口を持つプラットフォームを手に入れたのに、そのプラットフォームのユーザビリティが低くなりそうな決断はしないと思うけどなぁ
むしろ、Swiftは今までObj-C必須だったからネイティブアプリへの参入をためらっていてWebView一発みたいなアプリで済ませてた層へのアピールだと思うが
もちろん、これも希望的観測に過ぎないわけだが

なんでそんなにObj-Cが廃止して欲しいんだかさっぱりわからない。片方書けたらどっちも書けるだろマジで

3行でおk

要はSwiftは遊びには良い言語ってことだな
目くじら立てるObjC信者やエアプログラマがいるけど、面白い言語だもんな
アポー信者と楽しく遊びたいね

AppleがObjective-Cを収束するとか言わなければこんなに荒れないし
SwiftはSwiftで楽しむ人もいただろう

×収束
○終息

Appleはそんなこと言ってないだろw
言ってるのはお前さんみたいな煽りと、Qiitaの意識高い系エンジニアだけだ
あとそれに煽られたObjC信者もか

>>457
Pure-Objective-Cアプリは今後リジェクトされるってことは終息方向じゃないのかと
http://www.slashgear.com/for-scholarship-students-at-wwdc-swift-is-mandatory-14378923/

> Your Mac app or iOS app must be written in Objective-C and Swift,
> or written entirely in Swift.

すぐ信者いう奴ってバカなの？

なんかすげえ脳内変換を見たぞ
> Your Mac app or iOS app must be written in Objective-C and Swift,
> or written entirely in Swift.

MacアプリまたはiOSアプリはObjective-CとSwift、またはすべてSwiftで書かなければなりません。

それは変換前でしょw

ObjC派がこのスレの上の方で煽ってた内容そのままをさっきの記事がドンピシャで否定してて笑った

Swift is no longer optional. Swift is no longer a ‘maybe I’ll toy with this one a bit’ language. Code in Swift or stay home, kids.

Objective-Cのみのアプリも許されるなら
written in Objective-C or Swift
になるがそうなってない

Qiitaと同じレベルで笑い所だろw
去年のWWDCのAppleのサンプルコードは半分以上がobjcだったけど、今年は頑張るのかねぇ

qiitaってあかんのか？

今年の奨学金のお題はswiftだよ！
ってこと以外の情報は読み取れないけど。

Qiitaは直近一年のSwiftの記事で検索して便利？に使うよ
それ以上前の記事は言語仕様変更や流行遅れなことが多いから見ないけど

Foundationがswiftに書き換えられてからがswiftの本番かもね。

ところでFoundationがオープンソースになったってことは
マルチプラットフォームになるのかな。
Webassemblyと組み合わせればwebアプリもswiftで書くという選択肢も出来てきそう。

betaの頃に夢見た話だな
小さなランタイムが全ブラウザに移植されるわけねーってフルボッコだったけど

>>469
github見てたら普通にlinuxサポートしてんのね。
流石にwindowsはサポートしてないけど
osxやiosのカーネルがlinuxに変わる布石だったりして。

Swift終了

>>471
goやrustはwin, linux, mac, android, iOS, mips, arm, etc.とやってるけどな
当然クロスコンパイラ混みで

swift 3.0でもホストコンパイルのままになりそうなSwiftに
クロスプラットフォームは期待しちゃダメだ

Windowsは10なら既にSwift動いてなかったっけ？
どっかで記事見た気がする

常識的に考えればObj-Cを捨てるとかカーネルを全然違う系統のものに変えるとか、システムの互換性や安定性を極端に下げるような方針転換はしないと思うから、
馬鹿なんじゃないのかと批判しようと思ったけど、
68kからPowerPC、Mac OSからMac OS X、Power PCからx86へと尽く過去の資産を切っていったAppleに常識は通じないのかとふと思った

けど、本当にそんなことが起こるんだとしたらしばらくApple製のOSの完成度が下がってユーザー離れるだろうから、別のプラットフォームでの開発もできるようにしといた方がいいだろうけどね。

これからGoogleやMicrosoftと凌ぎを削って開発者の獲得を目指すのに、対応言語を増やす事はあれどなぜ既存のものをすぐ廃止する、廃止できると考えられるのか？
近視眼的なプログラマ目線でなくて経営から見た方がいい
一本化によるコストダウンもあるにはあるが移行コストも莫大なわけで、これまでのアップルの資産は数年でリプレイス出来るレベルじゃない

それにこれは主観的な意見だが、ジョブズと違ってクックには一本化なんて事をやる思い切りの良さは無いと思う
しばらくは両輪でSwiftの盛り上がり次第でどちらにも転べるようにうまくやるだろう

GoogleがSwiftってのが嫌だ！Appleのそばに来るな！
クックはバカっぽいからSwiftは大失敗すると思う。
・Watch売れてない
・デカイiPad Pro売れてない
・iPhone SE売れてない
ジョブズ居なくなってから何も売れてない。
バカなんだろうな。

obj-cの終焉はiPhone時代の終焉

まぁ、本当にObjCだけで良かったのなら、わざわざ新言語のSwiftを作る必要はないわけで。
Apple様がこれからどちらに注力していき、どちらを終わらせるかは、明白だと思うけどなぁ。
今年のWWDCは、Swift 3.0以外にも何か大事がありそうで、今からとても楽しみ。

話題作りで株価操作だろ、新しいframeworkならともかく新しい言語なんか覚えたくもない
どうせ結果は同じなんだから

クックはやり方が下手。
おいおい！AppleのツールはSwiftって言語で書かれてるらしいぞ！
みたいな口コミみたいなところから持ってけばいいのに、1.2なんかクソだったしとりあえず3.0からまた始めるよ。

しかし・・WWDCのポータルに熊本へのお悔やみなかったな・・。

swift専用、obj-c専用、のxcodeがいいんだけど

Objective-CとSwiftの両方用意しときゃいいだけだろ
でjs厨的なやつも取り込みつつ現状の開発者はキープ
メンテの工数がきついとか舐めたこと言ってんじゃねぇぞApple

Swift終わったな

>>476
ジョブズのsecret double life 忘れたかw
2000年の時点でOSX Intel版も出そうと思えば出せたと思われる。

http://www.infoq.com/jp/news/2015/03/apple-uxkit-framework-found
uxkitって話題になったけどいまだに出る気配ないよね。
上記によるとUIKitの再描画コードがシングルスレッドである点を問題視してるけど
androidでも同じだし、
マルチスレッドで動作するUIFrameworkってモバイル、PC含めて存在するの？

AndroidのSurfaceView

Swiftって、やりようによってはViewController.swiftに全クラス書けてしまうわけじゃない。
どういうときに他の.swiftファイルに分けるべきだとか、決まりごとみたいなのってある？

ViewController.mにも全クラスかけるよ。

objcのお作法に合わせるのが普通じゃないかね

>>479
で、Obj-C終わらせるとして、今まで書かれた大量のObj-CによるMac OS Xのシステムやアプリケーションのコード、iOSアプリはどうなると思うの？

>>491
今までアップルがやってきたやり方を振り返れば考えるまでもないんじゃない？ ObjC触ってるならにわかなアップル歴でもないよね

c/c++ で書きたい部分はなくならないんだから objc が無くなる訳がない。

煽りに反応してるアホはまとめてアンチスレに行けよ

無くならないのと、終わってないのは、違う意味で使ってるなぁ

例えば別の技術で言えば、
Flashは今後もなくならないだろうけど、もう終わってるよね
CoffeeScriptも、無くならないだろうけど、もう終わりに向かってるよね
日本の家電メーカーも、無くならないだろうけど、もうメインストリームではないよね
そういうかんじ

objc厨は文末にセミコロンを付けてくれないかな;
区別しやすくするために;

そ;れ;な;

return 1;
}

僕はswiftユーザーだけど;
swiftは衰退すると思うね;

>>495
本当にそうなんだとしたら、せっかくAndroidに比べてメディア系がiOSは強いっていうアドバンテージがあるのに、わざわざその強みもなくすとはAppleもつまんない企業だなぁ。

Swift信者じゃないんですけど!
Obj-Cの…大学?に通ってるんですけど!

appleは移行が得意な会社だと思うよ。
MacもOSをNextStepベースに変更したし
CPUアーキテクチャも何度も変更した。今はintelとarm両方にすら対応した。
２つの状態を共有して十分普及したら古い方を切り離す
という移行の仕組みで何度もCPUアーキテクチャだったりOSだったり
変更を行ってきた。

手始めにFoundationをswiftべーすに書き換えてるから
ちょっとずつobj-cのライブラリをswiftに置き換えていると思う。

アーキテクチャの変更はコンパイルし直すだけでだいたい解決するようにAppleがうまくやってくれたわけで、Objective-CからSwiftへの変更はCarbonからCocoa並みのインパクトと労力をサードパーティに強いるよ。
もし本気でSwiftへの移行を推し進めるのならApple純正のコンバータを提供してくれるかもな。

AppleがSwiftに移行していくと言わなければ、ほとんどのやつは
すでにコード資産もたくさんあるだろうしObjective-C使うだろうな
Swift使うのは意識高い系だけだろ

Appleのモノは全て素晴らしいという訓練された信者と
ウケるオモチャが出来たと遊ぶハカー(笑)が使ってる

業務常時利用は辛いけど、普通に面白い言語じゃないか
betaから使い続けて慣れたらコーディング効率はobjc相当にはなった

Swiftは書いてて楽しくないんだよな。
GCDもSwiftっぽくかけるだけで動作は全く同じでクラッシュしてもどこかわからない。
意味なく表記を変えたい人だけSwiftやればいいよ。
obj-cにもなんちゃってgenericsとnullable導入された今、どっちを使うか賢いやつは知っている。
新言語なんか覚えるのはナンセンス。

アンチスレへどうぞ

Swift終わったな

ファンクタ、アプリカティブ、モナドがSwiftを使ってわかりやすく説明されてる
http://www.russbishop.net/monoids-monads-and-functors

Objcでは無理そう

ざっと読んだけどブロック分やジェネリクスの汚いコードなら出来るんじゃね
Swiftも十分に汚いからどんぐりの背比べだけど

functorの説明からこけてて笑った、無理に Swiftで解説しなくてもいいのよ
> Swift can't represent Functor

>>508
当初変態呼ばわりされたObjective-Cが霞んで見えるほどクソすぎるシンタックスだわ

アンチCを拗らせすぎてどんどんクソ構文になってきてるな
もっとうまくやれよSwift
バカなの？

>>508
objc なら c++ のテンプレートを使えばよい。

>>495
MacもiPodもiPhoneもiPadも、登場時はこんなもの売れるわけ無い！って叩く奴多数だったけどね。
ライバルのネガキャンだけじゃなく、本当にそう思ってる者が多かった。
今から見れば、理由は簡単で、「従来からある何かの変種」だと見做そうとしてたから。
言語や製品のあるべき未来に近づいてるか？という目で見る人は少ない。

配列ってなんで添字アクセスした時Optionalで返ってこないの？
辞書はOptionalで返すのに一貫性ないじゃん

煽りのわりには愉快な構想だなぁと関心した
当然無理な構想だけど

>>511
うまくやったら喜劇じゃない

おそらく数年後には、、、、

SwiftにC言語の要素を追加した、Swift-Cが登場すると思う。

Swift-C++ だな きっと・・・Swift-C# だったりして

>>513
iPhoneが売れるわけないって言ってるやつら見る目なさすぎって当時呆れてた俺だがSwiftはこの先どうなるか分からんと見ている

>>514
配列には何かしら中身が入ってるからで、辞書は該当のキーが無ければnilを返すからとしか言いようがない
配列のindexの範囲を超えた時はまた別のエラーが起こる

iPhone音声発信出来ないバグが多発してたから、、、
iPadはUS先行発売でビッグウェーブで日本人も食いつきまくりだったろ

Swiftは完成品をドーンと発表しなかったからショボイ雰囲気
NMBみたいに発表すれば多少は良かったんだけどなぁ
NMBも発表直後こそは良かったが散々な評価で後続が出る気がしないけども

>Swiftは完成品をドーンと発表しなかったからショボイ雰囲気
Appleらしくないよな
ジョブズ時代のAppleなら、最初からある程度完成度の高い状態で
お披露目して一気に普及させるようにリリースしてたはず
初代iPhoneだってそうだった
そういうところにAppleの凄さを感じたりもしていたのだが...

>>485のsecret double lifeがまさにそれだな
Swiftも確かに数年間Apple内部でこっそりやってきたんだけど世間に発表してから2年経ってもまだまだな感じ
あと数年経てば小慣れてきていい感じに普及するかもな

もう、javaかc#でいいじゃん

金使わないぞ！

そう、新しいものは要注意
お金を使わせられるだけ
経済活動に協力してはいけない

チケット買って行く＝負け組

チケットを買う金もない=負け組

Swiftの開発体制はこれまでのAppleでは行ってなかったような、だいぶOSSコミュニティ寄りの開発の進め方だよね。かなりオープンというか。

未成熟な段階でリリースしたのも、よく言えばフィードバックを得ながら変えていくためと取れる。そのせいで仕様変更しまくりだが

こんなポンコツ言語やってる奴いるの?

時代の流れに乗ってみたんだろうけど、信者がついて来ないやり方は失敗だったなぁ
逆ブレしたObjC原理主義信仰のアンチを増やしすぎた

Swiftは5.0から

Appleはオワコン

このスレ見てたら結局C#使うのが一番楽そうに思えてくる

>>513
iPod や iPhone,iPad はリリース前はともかく、リリース後は誰も普及しないなんて思わなかった。
Swift はどうだ? 上記の物とは全く逆の評価。
こんなの普及してほしいプログラマなんていないだろう。

Swiftは大人気で、プログラマーはみんなやりたがってる、
アンケートを取れば一番人気の言語だ、
とか書いてあるのを良く見かけるけど、そうなの？
実感がないのだが？

言語は素敵だけど、ライブラリが旧来のままなのが残念すぎる。

>>534
ステマに決まってんだろそんなの

Swiftは欲張りすぎだな。
without C なら、ポインタ操作だのnullableだの一切やめて上層だけで組めるようにすれば良かったんでは。
できる事は限られるけどな。

>>527
今のクックみたいにフィードバックをよく取り入れて物を作っていくよりジョブズみたいに独裁的に進めた方が良かったんじゃないのか
Appleには一流のエンジニアがたくさんいるんだし

>>513
ジョブズが停めてたのが目に見えてわかるぐらいswiftは退歩してる言語だから…
いや、違うな…Obj-Cもまた変なベクトルの言語だけれども
少なくともC++みたいなのが迷い込んだ袋小路からは距離を置いた言語ではあった。
swiftはね、なんか袋小路のどんずまりで頭ぶつけてた奴らが
袋小路から首だけ出して「新天地だ！」って言ってるような、
"いままでと同じ泥沼に浸かったままじゃねーか！"って言いたいつか
少年が「王様は裸だ！」って言わないとわかんねーのかこいつら？な言語なの。

多少は分かってるからObjC信者がいる
ここにヘイトしてくる狂信者っぷりは依然そのままだけど

>>539
ジョブズが停めてたってのは初耳。どっかにソースある？

俺もジョブズが止めてたって初めて聞いた
ソース出して

>>539
ジョブズが止めてたなんて嘘でしょ。

Appleの開発ツール責任者、Chris Lattnerによると、Swift言語の開発は2010年7月に始まった。彼は自身の個人ブログに、この言語が個人プロジェクトとしてスタートし、「存在を知っていたのはわずかな人々だけだった」と書いている。
2011年の終りに、数人の精鋭エンジニアがプロジェクトに加わり、Apple開発ツールチームの主要目標になったのは、2013年7月になってからだったという。

AppleがいつSwiftの話をやめるか今から楽しみ。
Swiftは一瞬だけ普及しておわる。

2009年6月ジョブズ休業
2010年7月ラトナー個人的にSwiftを開発開始
2011年10月ジョブズ死去
2011年終わりAppleとしてSwiftを開発開始

ジョブズ関わってないだろうな。下手したらSwiftの本格始動について耳にすら入ってない可能性もある。
んでその後は

2014年6月Swift公開
2014年6月Swiftリリース
2015年6月Swift2公開
2015年9月Swift2公開
2015年12月オープンソース化

こうしてみると歴史も浅いしまだまだこれからって感じだな

ジョブズが止めてたって話から、関わってないって話に刷り変わっててワロス

iOS 6だか7のMapにGoを出すジョブズならSwiftにもGoを出すだろ
MapもMac, iOSをまたがってようやく使えるようになったのでSwiftもあと5年は静観だなぁ

Swiftマンセーはステマ

ステマって単語久々に聞いたわ

>>546
俺はジョブズが停めてたって書き込みを見たから気になって時系列を調べてみただけだぞ
刷り変えってなんだ

Swiftなんかに踊らされるなよ〜

ゴミはゴミ箱へ
アンチはアンチスレへ

>>549
亡くなってすぐにAppleが絡み出したように見える

ジョブスなら objC の廃止までロードマップにのせるはずだ

「ジョブズ」で「ObjC」な

は？

ジョブズなら〜とかお前は大川隆法か

Swiftに踊らされてるよ〜

♪　∧,＿∧　　♪
　　 ( ´･ω･) ))
　(( (　つ　ヽ、　　　♪
　　　〉 とノ　)))
　　（__ノ^(＿)


　　　∧＿,∧　♪
　 (( (･ω･` )
♪　 /　⊂　) ))　♪
　　((( ヽつ 〈
　　 (＿)^ヽ__）

ob-cなんて記号だらけで読みづらいわ
swift今はガチガチだし整備されてない印象だけど今後もっと柔軟になるでしょ

そんなことはどうでもええねん
せっかく苦労してアプリ作ったのにiOSでしか動かんのが腹たつ

(´・ω・｀)良い言語は概念にしろ文法にしろ他にどんどんパクられる

ユーザー的には良いことじゃん
jsみたいに絶対的な地位が付加したらもっと楽しくなる
選択肢なんて無い方が良いわ
アプリのW3Cみたいなの結成してほしい

ジョブスがswiftに興味持つわけ無いだろ。
計算機のレイアウトのためにGUIのツールを作らせるくらいブログラミングに興味ないやつだぞ

モダン()な言語Swift
意識高い系のあなたにぴったりです

throwとdeferは失敗なパクリだと思った
optionalは慣れたら便利に使えるけど、あいつら使う日がくる気がしねー

>>559はlispの使い手

optionalなんかめんどくさいだけじゃん
絶対にSwiftなんか使わん

煽りがワンパターンすぎてつまらんぞ
もっと工夫しろ

いつも監視ご苦労さん

Swift終わったな

某大手は組み込みへの応用を視野にSwiftはスルーするってよ
ランタイムがクソデカイし

パクリ言語はダメだろ！？

AppleがいつSwiftをあきらめるか楽しみで仕方ないよな〜
今もこれからも時代はC#だよな〜
Obj-Cはそれなりによかったが、iOSのためにSwiftなんか覚えても先が知れてる。
また新しい言語来るたびに苦労するのか？
マゾなの？

Appleもついに終わるか・・
もう売れないプロダクト感満載だし
iPhone7もiOS Xもたいしたことなさそうだし
jobsが生きててくれたら・・

ID変え忘れてるぞ、どうした？

>>571
Swiftのクソさ加減は誰の目にも自明だからな
いかにごまかしてフェードアウトするかその方法を探ってるだろう

ライバルを増やさないように必死な工作が続いているというわけか…

以前の
プログラマーは儲からない
プログラマーは儲からない
プログラマーは儲からない

と同じ流れだ

>>575
ちょっと何言ってっかわかんないっすね
まさかライバル増やしたくないからとかいうしょぼい理由で
Swiftがクソだと言ってるとは思ってないよね？

そんな習得の難しい言語かよw
むしろ教科書的な言語だとすら思うわ
手になじむツールとしてはまだまだ未成熟なのは認めるけど

SwifterつうかAppleがオワコン

Appleの次に来るのはどこ？

JavaScript iOSフレームワークやってたらSwiftが随分便利だったなぁと死にたくなった
LL文法はいいんだが、JSに限らずネイティブ言語じゃない言語でiOSアプリ実装辛すぎシネ

C#でのiOS開発は楽ですよ

またUnity厨か

おいらはObjective-Cで楽しく踊るよ〜

♪　∧,＿∧　　♪
　　 ( ´･ω･) ))
　(( (　つ　ヽ、　　　♪
　　　〉 とノ　)))
　　（__ノ^(＿)


　　　∧＿,∧　♪
　 (( (･ω･` )
♪　 /　⊂　) ))　♪
　　((( ヽつ 〈
　　 (＿)^ヽ__）

いや、Xamarinのステマ厨だと思うよ
昨日はID変え忘れてたようだけど今日は大丈夫っぽい

毎日ご苦労

それにしてもSwiftは無いな・・

swift、それは書いていて楽しく無い言語

https://github.com/xamarin/xamarin-macios

実はFlashが一番だということに、最近気づいた
何でもコードを打つのは面倒に感じる

ねくらファンタジーマップチップ素材集
http://www.dlsite.com/home/work/=/product_id/RJ165626.html/?unique_op=af
マップにこだわりたい人向けの、高難易度上級者向けマップチップです。
森/洞窟/海岸/砂漠/荒野/マグマ洞窟/凍結洞窟/村/街/城砦/遺跡/異空間が作れます

イラストアイコン素材集Vol.1
http://www.dlsite.com/home/work/=/product_id/RJ154598/?deqwas_inflow=RJ165626&;deqwas_tg=item_view
総数900点以上(380点+色違い、模様違いなど差分549点)

optional否定してる人ってプログラミングを生業にしてるのか問い詰めたい
nilの可能性が考慮不要なスコープが作れるのはほんとうに便利だと思うんだけど。

obj-cのnilに対するメッセージ式がnil返すって挙動は問題の先送りだと思うし、
それが問題だと思うからswiftができたと思うんだけど。

あくまで言語一般として例外キャッチするよりは
転ばぬ先の杖としてはいい概念だと思う

オプショナル型はnilの可能性が残るんだけどね

コピペだろ

Cのポインタそのまま利用してるObjCとかはともかく、Javaとかはなんでわざわざnullの概念を引きずったんだろう

optional型なんか要らないよ。静的解析で十分。
BasicみたいなSwiftじゃ、まともなアプリ作れないし。

Optionalでスコープを切るのは使い方分かったんだが、静的解析のほうが融通効くんだよなぁ。

Optionalが有効なのは、スコープ内で使っているケースに限られる。
要はCだと
if (hoo && bar && func(hoo, bar)) {
}
と書くケースだけ。下記のケースなどには対応できないよね。
if (!hoo && hoo=func()) {
func2(hoo)
}

それに、無理にif letでOptionalを展開し、スコープ内で使わないと、使っていないと警告される。if letはnullでない事だけが必要な時に入りたいスコープって書き方には使えない。

Obj-Cが楽って感じるのは、こういうCのifをそのまま使ってるからだよね。一々!=nullとかく必要さえない。

ゴミはゴミ箱へ
アンチはアンチスレへ

>>597
だからまずおまえがゴミ箱に入ったほうがいいんじゃね？

単発IDでそれだけ言われてもな
ネタ出せネタ

オプショナル型とヌルポを混同しとるアホがおるな

ﾔﾚﾔﾚ ┐(´ｰ｀)┌ ﾏｲｯﾀﾈ

>>594
開始時とかに空っぽにしておきたいなんてシチュは山ほどあるだろ
いちいちnullクラス用意するなんて現実的でない

>>561
ジョブズは古いハッカー側の人だから職業プログラマーじゃないだけで
むしろ、コンピュータ関連の知識は君より広かったと思うよ。
あの人の怖かったのはコアの部分で技術を知ってるから
ハンパなもん出すと「これまだ不完全だよね？」ってガチで見抜いちゃう最高経営者だったってこと。

“Steve Jobs brainstorms with the NeXT team (1985)”

↑これ見れ。

これからもnullを返すAPIを作りまっせ！

Swiftはnull許容するなよ初心者の学習用途に専念しろw

未だにSwiftに移行できてない低脳がいるのか

今年のWWDCもSwift推しっぽいな
ついてこれない奴は取り残されるだけ

>>606
間違えたものを代入した時点で取り敢えず止まってくれるから初学者にはいいんじゃないの？

nilを許容しなきゃCocoaAPIも呼べないということにも気づかないアホにレスすんなよ

>>610のほうが絶対にアホだけど

大手キャリア、大手ゲーム、電通系、リクルート系、などの大手開発全部、obj-cスキル必須ですよ。

この辺がずっと曖昧なんだけど、
nilでメモリから消せるんだよね？
値があるってことはメモリ使ってるんだよね？
何が溜まってて何が消えてるのか分かりづらい
ハードに優しいswift設計の本とかサイト知りませんか？

あと、Xcodeでクラッシュした時にアセンブラ？みたいなのが出て
原因がわからない時が多いです。
あれどうにかなりませんか？

Debug -> Debug Workflow -> Always show disassembly
のチェック外したらアセンブリ表示出なくなるらしいね！
今まで何で検索できなかったんだろう。。

質問は質問スレで
あと質問内容はもっと具体的に

初心者ほどSwift使っちゃダメなんじゃねw

1日の売り上げが始めて2000円突破したぞ
ばんじゃ〜い ＼(^_^)／
1日1万円突破する日も近いなこりゃ

>>615
ごめん
optionalの会話が多かったから

>>596
全然中身を見てないけど変数の中身がnullかどうか静的に解決できないから
Optional型ができたんだが。

obj-cから勉強しろよ。

来年ぐらいにSwift-Cが出るよ。それまで静観だな。
ってことで、オロナミンCでも飲むか。

Swiftive-C

>>622
ｸｿﾜﾛﾀｗｗｗ

笑いどころが分からんのだけど解説して

>>624
アンチCなSwiftがCに寄り添うなんて皮肉のパンチ効いてるだろ

java8もオプショナル採用してるじゃん
あっちに比べれば読みやすいと思うけどね

言語として進化を追い求めるのはいいことだが無駄にwithout Cを
進めてるのが反感買ってると思う
もはやCっぽくないシンタックスにすること自体が目的になってるきらいがある

cの関数は呼べるけどな
enumとかswitchとかcより進化して便利になってる
c書く時もついセミコロンを忘れてしまう。まぁはっきりいって複数文でも書く必要でもなけりゃセミコロンは不要
進化についてこれないやつは釘とトンカチで家建ててろ

enumやswitchが便利になったのは分かるけどそれを進化と呼ぶのなら、今まで出来てた事が出来なくなったのは退化と言えるのかも知れない
切れるところはうまく切り捨ててフラグメントや人的ミスを減らしたいんだろうけど

クリス・ラットナーはなぜ未だにCが使われ多くの主要言語がCをベースの文法で作られて来たのか冷静に考えた方がいいな

Swiftの文法もCベースじゃん

GitHubで匿名通信（Tor、i2p等）ができるBitComet（トラッカーサイト不要でDHTだけで日本語検索可能）
みたいな、BitTorrentがオープンソースで開発されています
言語は何でも大丈夫だそうなので、P2P書きたい！って人居ませんか？
Covenantの作者（Lyrise）がそういう人と話したいそうなので、よろしければツイートお願いします
https://twitter.com/Lyrise_al

ちなみにオイラはCovenant(純粋P2Pのファイル共有ソフト)の完成が待ち遠しいプログラミングできないアスペルガーｗ

SmalltalkベースのObj-Cはキモいって散々言ってたのに、
今度はCらしさはキモいとか言い出して、自分らしさの旅に出てるのはおもろい

ゆうてもObjective-CはCだからな

プロトコル指向で思考するのが至高

シコシコうるせーよ

ES7のasyncっぽく書けるようにならんかな

ぬぁるぁんっ！

>>631
えっ

Swift.netはよ

>>637
あんまりPromiseを便利に使ったことないけど、PromiseKitの使い心地を聞きたい

【Swiftでクリエイティブコーディング！C4とは】
http://hackist.jp/?p=7345

うぉっ、こんなのがあったとは知らなんだ
Swift学習にもなるし手元のiOS端末を活用できるのは大きいな

うぉっ、じゃねぇよ
p5スレとマルチポストしてんじゃねぇぞ死ね

SwiftってJSみたいにブラウザとかサーバーで動くようにならんのかね？

Frameworkの移植がまだまだ必要だけど一応Linux版が少し動いてるらしい

>>645
ああ、まだ全然使えないらしいね。
使うとしてもレンタルサーバーでは厳しいか。

Webでやることなんて大したこと無いし、コンパイル一瞬でできそうだから擬似オブジェクト指向のスクリプト言語に依存する意味がわからんのだよね。
Swift始めてからよく言われてるJSやらPHPのガバガバ感が気持ち悪くて仕方ない。
やっぱスクリプト言語の方が制作的に断然早いの？

コンパイル言語のJavaやC#を使ってWebアプリ作るには環境整えるのがめんどい
tomcatや.net等のフレームワークの類
その点、スクリプト言語はWebサーバのモジュールさえ用意すれば動くし、トライ&エラーで直ぐに動作確認できるから便利っつえば便利
SwiftをWebサーバと連携させるにはまだまだ環境的に足りないよね

せや！
JSが進化すればええんや！
DOM操作系では最強だし。

ある程度規模が大きなコードになってくると
型きっちり決められる言語で高機能IDE使って開発したほうが
後のメンテとか機能拡張とかすごい楽だよ

>>648
先日のID変え忘れから、ID変えるのやめたんだろうけど、私利死滅といか、意識散漫というか
一貫性がないからID変えた方がまだ良いな

>>650
だってswift自体完成してないのにサーバーサイドとかDOM操作用のAPI?SDK?とか夢のまた夢だと思ったんだもん。
他社のブラウザでswiftが動くとかも想像出来ないし、、
それならブラウザ掌握しててサーバーサイドでも動くJSがswift的に進化する方が現実的かなって。

Swiftの胡散臭さに一役買ってるのはQiitaと意識高い系のカスどもだろ
余計なことすんなよ

Pythonが駆逐するんじゃねえかな
ここ最近破竹の勢いだし多分覇権言語になるでしょ

そのうちSwiftで書いてWebAssemblyにコンパイルしてブラウザで動かせるようになるんじゃね

OSSになる前のLLVMだからどこでも動く、というロマンと同じだなw

小さな10M弱のランタイムがないと動かないからムリだろ
iOSネイティブであのサイズ、WebAssemblyでも同等以上のサイズになって
そんなランタイムDLさせるのはありえんわ

ロマンを実現するならランタイムが極小になるようにswift compactみたいなサブセット規格でも作るかねぇ

そもそもWebアプリでSwiftである必要がないだろ

swiftである必要が無い？
じゃあ一生新しい言語を追いかける事を受け入れるの？
俺は嫌だな、せめてこの場でだけでもあらがいたい。

swift compact？大歓迎だよ！

Swiftに限らず強い推進活動はやがて排他的な活動へと発展し争いを生む
人間はいつまでたっても学ばない生き物
戦争もなくなんねぇよそんなんじゃ

だって毎回当事者が違うだろ

別に排他的にならなくても選択肢としてSwiftが増えるだけでしょ。
JSしか選べないフロントエンドの現状が異常なのでは？
web屋なんてJSからSwiftに乗り換えるとか楽勝、むしろ歓迎じゃない？
jQuery的なライブラリも当然出る前提だけど。

そういう風になっていけばSwiftだけしか使わなくていい人も増える。
ライブラリもエディタも増える。知識ある人も増えて良いことづくめ。

Webのクライアントサイドに限ってはサポートする言語は１つでいいよ
VBスクリプトと混在するJavaScriptの亜種で混沌としてたあの時代に戻るわけにはいかない

>>658
ワロタ
Swift, ObjC両立を許容しない排他的なObjC信者への煽りかw

イマドキ言語を縛るのはナンセンスだとWebブラウザ版LLVMを作ろうと Web Assembly なんだろうから
Web Assemblyのロマンを実現出来るかは別として一つの言語がマルチプラットフォームで動くのは歓迎したい

だから、Swiftのクロスコンパイルを早くしろ
あとWindowsでも動くようにしろ

>>662
>Swift, ObjC両立を許容しない排他的なObjC信者への煽りかw
いやいや両立を許容しない予定なのはApple自身だろ...
両立を許容する宣言しとけばこんなゴタゴタは起こらないかと

Appleはそんな予定を表明してませんよw

いやいやObjective-C→Swiftへの移行を強行してるでしょ

してないと思うけどw

ob-cが終わるとは言ってなくね？
c++も使えるでしょ。メンドイけど。

つーかどうせコンパイルしてバイナリなりアセンブリに変換するならどれでもええやん的な。
javaだってxcodeが対応すれば動くんでしょ？
あれか、SDKが互換性ないんか。

Obj-Cにもそのうちオプショナル型が導入されるかもな。無理やり感満載で汚くなりそうだけど

導入しなくても全部オプショナルでしょObjCは。

ん？

>>666
え？そうなの？
Objective-Cを引き続き使いたい人は使えて、Swift使いたい人はSwiftで書いてが許されるってこと？
だったらぜんぜんええやん
何も問題ない

>>672
今はob-c案件に固まってるけど今後仕事で使うならswift案件もこなせないとな。
swiftから入った人間はob-c勉強する気起きない人多いから有利だと思う。

obj-c案件とかswift案件とかあるのか

一周回って？減ってきてるけど、swift案件は昔は結構見たぞ
アポーが作った新しい言語！これは素晴らしいはずだ！！と踊らされた上流行程がSwift強制、そして炎上
1.xの頃はこのスレもその手の苦労話多かったわ

なんで苦労したんだろ
経験不足とか？

今もそうだけどswift(xcodeの)アプデの度にとんでもない数のエラーが出る。
swift3.0はまたもの凄い書き直しが予想されてる。
作りっきりのアプリならいいけど今大きなプロジェクトでswift使うとアプデの度に死ねる。

それが理由で工数が無駄に掛かるから最近はswift案件が激減してる。
というか業務ではほぼ絶滅。
開発途上の言語というのが周知になった以上、あと数年はswift案件は無いと思った方がいい。

受託開発で相手がSwift使いたいって言ってきたら工数増でウマー
自社案件なら使わない。結局使い分けよ

逆でしょ
受託案件で客がSwiftリスクを理解して、増加した工数分金を積んでくれることは稀
自社案件は技術アピールと、Objective-Cが死んでも生き残れるエンジニアを育成するためにSwiftを使う

>>674
ほんそれ
本当に両立する気なら開発者が好きなほう選べばいいはずだがそうじゃないってことだろ

>>681
いや、好きな方で書けばいいよ；
どっちで書いても同じように動くんだから。
でも客やチームリーダーに指定されたら従うしか無いって話。
エラー書き直すって言っても、アプリをアップデートする際に必要なだけで、バイナリ化してストアに出してるアプリが急に動かなくなるって話じゃない。

Apple的にはどっちで書いてもいいけどswftの方が書きやすくなってるし、一瞬でビルドできるおかげて新しい機能（@IBDsignableとか）も使えるからどんどん使ってねー的なスタンスじゃないの？

サードのライブラリはob-cとc++の混在パターンが今は多いけどswiftでも共存できるし、swiftしかやったこと無くてもUIKitが同じだから全く読めないこともない。
極論言えばob-cで作ってるチームの中で自分だけswiftでクラス作ってても共存できるから結局個人の好きな方で書けばいい。
ob-cに至ってはコード中にc++をシレッと混ぜても動くカオスっぷり。

Xcodeってそういうぶっ飛んだシロモノなんだぜ？
頭イカれてるとしか思えないフリーダム仕様なんだぜ？
ジョブズきもいだろ〜

すまん。ちょっと飲み過ぎたわ。
これは酷い

結局、ここ5年間はobj-c知らなきゃ仕事はない。
そのうちにSwiftは死亡する。

Swiftってインタプリタ実行言語みたいでキモイ

>>683
賢者タイムかよｗｗｗ

>>680
上乗せ出来ないプロマネはシネばいい
それこそずっと言われて来たことだ

ObjCとSwiftの機能が対に存在してなくて
ObjCでこうする場合、Swiftだとどうすればいいんだって問題もあったな
String周りとか機能不十分な上に仕様を何度も変えるから困ったわ

Swiftなんてobj-C知ってれば3日で覚えるんだから覚えればいいだろ
覚えたからって別に害になるわけでもなく

覚えてもすぐ仕様が更新されてイラっとするからもっと先でいいや

>>688
3人日が勿体ない

人生に余裕なさすぎw

ついに人生観を語り出したか
末期だな

人生観ってw 大げさすぎ

人生持ち出したんはお前だろ

リラックス、リラックスw
ていくいっといーじー

うーんｗ

>>688
それな
こっちはすでに全面的にSwiftに移行した
Objective-CでもSwiftでもどっちでも開発できるが、新規案件は全てSwiftに移行

Objective-CモドキのSwiftを書くのと、
Swiftの標準ライブラリレベルのSwift書くのとじゃレベル感違うからなー

特にProtocol Extensionを前提とした設計は難しい
ダイヤモンド継承問題を再燃させている

今Swiftで書いておけばメンテナーがいなくてアップデート案件も自分のとこに回ってくるしな

一旦Swiftに移行したらもうobj-cには戻れませんわ
obj-cでのプロパティ宣言とか、型宣言必須とか、カッコ構文とか、ヘッダと実装がファイルで別々になるのとか面倒くさすぎてもうね

ObjCの自前ライブラリはどんどんプロトコル指向でSwiftに書き換えていってる
今やSwiftの方が開発しやすい

バージョンアップ時の修正なんか、Swift移行で上がった生産性で払って余裕でお釣りがくるよな

基本的にコードは書くより考える時間の方が長いから、
Swiftで記述量減ってもそこまで生産性上がらないんだよなぁ
あと、ビルドがまだ重い、リファクタリングできないという生産性への負のインパクトが大きすぎる

>>698
ライブラリ書くとObjC互換 IFにしようとしてObjCもどきのSwiftになる罠
あとSwiftライブラリのXcode versionに引っ張られてXcodeのversion上げられない地雷もツライ

アプリケーション層ならSwiftらしく書けるんだけどなぁ

プロトコル指向なんてプロトコルで超小分けに細分化してパーツ組んでクラスに合体させるだけとちゃうのん？
クラスの参照とか気にしなくて良いらしいから精神衛生的に良いってくらいにしか良さがわからん。

匿名通信（Tor、i2p等）ができるファイル共有ソフトBitComet（ビットコメット）みたいな、
BitTorrent（Covenant）が活発な情報交換・交流コミュニティでオープンソース開発されています（プログラマー募集中）

言語は何でも大丈夫だそうなので、P2P書きたい！って人居ませんか？

Covenantの作者（Lyrise氏）がそういう人と話したいそうなので、よろしければツイートお願いします<(_ _)>
https://twitter.com/Lyrise_al

ちなみにオイラはCovenantの完成が待ち遠しいプログラミングできない情報発信好きアスペルガーｗ


The Covenant Project
概要

Covenantは、純粋P2Pのファイル共有ソフトです

目的

インターネットにおける権力による抑圧を排除することが最終的な目標です。 そのためにCovenantでは、中央に依存しない、高効率で検索能力の高いファイル共有の機能をユーザーに提供します

特徴

Covenant = Bittorrent + Abstract Network + DHT + (Search = WoT + PoW)

接続は抽象化されているので、I2P, Tor, TCP, Proxy, その他を利用可能です
DHTにはKademlia + コネクションプールを使用します
UPnPによってポートを解放することができますが、Port0でも利用可能です(接続数は少なくなります)
検索リクエスト、アップロード、ダウンロードなどのすべての通信はDHT的に分散され、特定のサーバーに依存しません
１

死ね

生まれろ

趣味でスウィフトどころか、プログラミングをはじめてはじめたものだがかなり楽しいわ。
必ずしも仕事に繋がる必要はないよね？

ここそんな人ばっかだよ。

Swift使いたくて使ってる人ばかりだからね
実用性はどうでもいい

おまえら立派なスウィフターだな

Swift終わったな

Swift始まったな

Swiftやってるな

Swiftクソだな

馬鹿には理解できない言語だな

と思って悦に浸ってる勘違い意識高い系バカが使う言語だな

愉快犯同士の空中戦やめい
ObjC信者もSwift使いもポカーンだわ

ObjCの狂信者がSwiftの動向にビクビクしながらこのスレ覗きに来てるのが笑えるわw

どっちの言語も書けるスタンスで双方のイマイチなところを批判してももう一方の信者だとレッテル貼られるのが匿名掲示板の辛いところだな

>>721
双方のイマイチなところを具体的に頼む

Swiftはwithout CだからインラインCが書けない
Objective-CはC拡張だから制御文はCのまま
やっぱSwiftive-Cだろ

好きな言語使えばいいのに何をいがみ合ってるんだよｗ

現場で必要とされるヤツを使えばいいだけ

どんだけCが好きなんだよww
インラインCって意味分からん、他言語コードがコピペで動くものなんぞ要らんわ
無理にやるなら、JSのevalみたいに実行時にステップ実行か？

マジレスするならお前はObjective-C++使え
Cが書けて型推論もジェネリクスもexceptionもクロージャも何もかもがあってObjC, Swiftの上位互換
実用上マイナーだから使いにくいけど最強の言語だと思ってる

荒れるのはObjC厨がこのスレ書き込むから

Swiftのことが気になって気になって気になってしょうがないんたろうな

>>723
それじゃObjective-Cでいいってことになっちゃうからダメだろ

CGPointとCGPointMakeの違いを教えてクレメンス

質問スレ行けっていわれんぞ。
CGPointは参照のみだったかも。
だから自分で数値入れる時はmake使うってだけだと思う、俺もはっきりした記憶ないけど。

それよりストリングindex面倒臭すぎじゃプロトコル指向なんてプロトコルで超小分けにパーツ組んで合体させるだけとちゃうのん？ね？
ちょっとしたことなのに何行も書かないと出来ないこと多い。
今例えようと思ったけど出てこんかったスマン。

>>722
スタンスを明らかにして改めて書いたら俺の言ってる事の証明にはならないけど、これまでに何回かスレには書いててるよ
>>722
イニシャライザが違うだけで結果は同じ。後者はSwift以前からあった初期化関数。Swiftらしい書き方という事で前者が登場した。どっちを使ってもいい

>>731
悪い、何か勝手にコピぺ入った。
正しくはこれ↓

それよりストリングindex面倒臭すぎじゃね？
ちょっとしたことなのに何行も書かないと出来ないこと多い。
今例えようと思ったけど出てこんかったスマン。

KVOがないのはクソ仕様

>>731
違いあるの？あったら嘘教えてる事になるな。ごめん。

ググったら「【iOS】CGPoint()とCGPointMake()の違い」というくだすれ行きなQiitaがトップにヒットしたわな
>>730は、このページで理解できないなら公式サイトのSwiftマニュアルを読み直せ、という話だが
CGPoint() ... 構造体のコンストラクタ
CGPointMake() ... 構造体を返すメソッド

返す実態は両方とも構造体の値型なので、機能に違いはなさげ
性能は・・・後者の方が2倍弱速くてワロタ
ホント、Swift発表時にObjCより早いとか言ってたのはどういうベンチマークだったんだよw

オーディオデータの取り込みに詳しい方助けてください
CMSampleBufferの使い方がわからず苦戦しています。海外のサイトをみても全くわからず路頭に迷っています
http://teratail.com/questions/34067

>>736
おお俺も勉強になった。ありがとう。

>>688
実際敷居は低いと思うわ
javascriptやlinqに似たところある気がするし、実用的なものになるかどうかはさておきobj-c知らなくても書けるしね

>>739
おれは逆に色んな言語の違いがわからないんだよね
大学の時にＣやった程度だけどjsもphpもswiftも大した違いがわからないまま割とすんなり書けるようになった
細かい書き方に違いはあれど基本同じに見える
機能的な問題？

非オブジェクト指向とかアセンブラとは違うのわかるけど、、

>>726
vc++よりもいいの？

>>740
なでしことHaskellとnimとLispくらいはやってみれば？
動作環境も用途も機能も大体同じ言語やってたら、そりゃ多少の意識高い系なら同じに見えるわ

>>742
なでしこ聞いたことあるなー
日本人向けって言ってたから興味あるかも

言うて戻すのにいちいちリハビリするのめんどい、、
基本プログラミングは言語統一してくれ派閥なもんで

なでしこはオワコン

なでなでシコシコ？

この程度にリハビリが必要とか言うから意識高い系なんだよ
どの言語も同じ程度に読み書き出来るなら弘法筆を選ばずで何の問題もなかろう
言語に依存する機能や特性、性能を気にしてないなら、尚更言語文法くらい気にせず使えるようになれよ

なお、SwiftはObjCと機能、特性はほぼ一緒で性能は下位互換
文法くらいしか楽しむ所ないから困る

リハビリにSwiftは適さないので、他の言語をお勧めする

WWDCでswift限定の何かがあるのか。
http://japan.cnet.com/news/service/35081399/

SwiftはObj-Cの上位互換言語

Swiftから他の言語に戻った時の弊害

文末のセミコロンを忘れる
if文の()を忘れる
switch文のbreak;を忘れる

>>749
ちょっと何言ってっか（略

>>748
フレームワークのSwift移行計画を発表するんじゃない？

バズワード並べただけのブロガーホイホイではなかろうか
>>748がブロガーかどうかは別としても普通に釣り上がってるし

よくて、なんとかKitをSwiftから叩くとMac OS, iOS, watchOS, tvOSがこのように連携できます(ﾄﾞﾔｧ
だと予想

そんなことよりswift 3.0の真面目な進捗報告を願いたい

>>740
forthをお勧めする。

進捗報告も何もオープンなのに

GitHubみろよ

お前ら純粋だなw

オープンソース=全ての進行が公開されている
と解釈できるほど俺は純粋じゃない

WWDC で ObjC の切り捨て発表

コミュニティを裏切ってまで裏で進めるメリットって何だ？

xcodeのハイブリッド化とかは？
もうできてるんだっけ？

何と何のハイブリッドよ？

swiftからcライブラリとか使いづらいのは、
obj-cとのすみ分けだと思っている。
cやc++のライブラリを使いたい時にobj-cでラッパーコードを書いて
swiftからobj-cのインターフェース呼び出しのコードを書いていくと
便利。これで住み分け出来てるからswiftとobj-cは共存共栄できると思う。

単純にやる気がない、手が回ってないだけだと思うが
C++が叩けないのは他の新興言語も同じだからいいとして、Cの叩きづらさ叩かれづらさは尋常じゃない
2.0で若干改善したけど3.0でもう一度一新してくれねーかなぁ

>>759
Androidも建前上はAOSPコミュニティの持ち物だけどGoogleが裏でゴリゴリ進めてGoogle I/Oでﾄﾞﾔｧってやってるじゃんよ
コミュニティ主体のOSSと企業主体のOSSじゃ進め方は違って当然

>>761
win/mac
期待はしてないけどiOS/Androidも。
せめてPlaygroundだけでもiOSで試したい

>>763
うん、で、Swiftでそれやるメリットは何なの？
Androidの場合は新機能をライバルに知られないことと、発表会を盛り上げられることが考えられるけど

>>764, 761
iPad版は出てもおかしくないと思う。
winやAndroidはどうでもいいと思う。大して売り上げに影響しないだろうし。

タブレットで本格的なプログラミングはないわぁ

without Cなら、obj-c++使うからいい

swiftive-c++希望、NSプレフィックスは取るな

>>765
Swift 3.0で発表会盛り上げてどうぞ
goやrustをライバル視してるならそっちへの牽制もあるか？逆にswiftがパクることの方が多いけど

>>764
開発者の囲い込みに成功してるAppleが他社プラットフォームにわざわざ塩を送らないでしょ
MSは囲い込み競争に負けてるからMacでも開発できるような体制になっけども

キーボード付きタブレットは昔のDOS入りノートPCと同じだからな。

>>771
Linuxで動かしてなんでWinで動かないんだよwwwwって笑い者になってるから
WWDCじゃないとしても早めにやるんじゃないのかね

ない時はそんなもの要らないと言って、出来たらヴォースゲー流石アポー！！
と絶賛するのが訓練された信者の在り方かもしれんが

cygwinポートなら既にマージされてるけど

>>743
「プログラミングは言語統一してくれ派閥」とか言ってる時点でなぁ
プログラミング言語はそれぞれ目指す目標が違うんだから、そんな未来は来ない
実際に何か書いて動かす必要があるのなら、複数言語覚えちゃうほうが明らかに手っ取り早いし、普通みんなそうしてる

そもそも、プログラミング言語だけ統一したところで例えばサーバーサイドとアプリとWebでは作法が全然違うし、
アプリですらプラットフォームごとにUIの思想はばらばらな訳で、世の中がiOSとMacだけになるとかそういう状況にならないと一切旨味はないと思うぞ

そんな夢を見続けているのって無意味じゃない？

>>771
CやC++やる本物のギークはLinuxだし、量産業務プログラマはWindows PCだし、
Macが囲い込みできている開発者ってオサレ気取りのワナビだけじゃないの？
高いハードのお布施で伸びてきたけど、Apple Watchがコケて先は見えない

アプリはソシャゲくらいしかお金にならないから、
本物の業務の現場でプログラムやってるWin層からマージン取る方にいくんじゃないかな

つい無駄に雄弁になってコンプレックスを悟られちゃうタイプかな

コンプレックスというか危機感かな
Windowsの仕事は10年先もあるだろうし、C/C++やる本物のプログラマはずっと必要
Swiftエコシステムをマネタイズする仕組みを作らないとみんな飢えるよ

>>773
レスのアンカー辿ってくれ
言語じゃなくてXcodeの話だぞ

初心者の俺にはxcodeで予測変換でるのありがたいんだけど、他の言語？というかソフトでもでるの？

>>773
よくわからんがUNIXで動いてるものをUNIX同士で移植したの見て
なんでおれたちMicrosoft社の独自規格OSでも動くようにしないんだ！って
言ってるバカがどっかに居るってこと？

Xcodeのwin対応でアプリが増えることも、開発者プランの加入が増えることもAppleとユーザー双方にメリットがあることだと思う。
macが買えないとか会社の都合でwin使ってる人だってiOSは持ってたりする訳で、そこにswiftを学習する機会を与えれば将来的にプラスになると思うんだけどなー

Xcodeは何もiPhoneアプリ開発専用じゃないんだが
Win版が出たとしてMacアプリの検証どうやんの？

>>781
goやrustがMac, Linux, Win, Android, iOS, MIPS, x86と対応してるのに後発のswiftが出来てないことへの皮肉、分からないのかな？

>>783
ブーメランささってんよ
Mac OS, iOS専用じゃないから、それらが開発出来る必要ない

>>782
Appleはハードを売ってる会社だからそう簡単な話じゃないと思う

>>784
Xcodeで何つくるの？

>>786
apple watch
apple TV

普通にiOSアプリ作る前提で話してた。
winで実機テストできたらiOS機器も少し伸びるだろうし、
iOS使って簡単にでもswiftの学習が促進されれば将来のMacユーザーやApple信者も増加すると思うんだ。
おまじないが無くて書きやすい言語だからこそユーザーを引き込む力が強いと思う。

>>786
IBMがサーバサイドSwiftとか考えてるから(棒読み

>>788
開発者側の環境を整えたらどうしてiPhoneが売れるようになるの？
自分がiPhoneだったらAndroidを、AndroidだったらiPhoneを、「開発環境が良くなって魅力的なアプリが増えました！」って売り文句で買う気する？

iOSアプリ開発でお金稼ぎたい人、企業はまずMac miniとか買っちゃうから。
WindowsでXcodeが動いて欲しいとか言ってるのはWinノートしか持ってないけどiPhone持ってるみたいな大学生だけだろ？

まぁ、WindowsPhoneアプリで一儲けできるなら
安いWindows機を買ってやらないこともないっつか
むしろその場合に逆に「Macだけで開発できるように公式互換エミュ作れ！」とか言ったら
完全に狂人の戯言だよなぁ…
そんな環境で売り物テストしたくねぇし、ドザがナチュラルに
気が狂ってると思うことは多い。

>>790
winでiPhone使ってる人めっちゃいるよ？
アプリ作ってみたいってだけでMacに乗り換えるってのは仕事の関係もあったりして難しいと思う。
winとかiOSでXcodeが出ればディベロッパープログラムの加入だけでも凄い利益になるし、これからはGoogleみたいにappストアで広告枠作るらしいから開発者人口は多い方がAppleは儲かる。
宣伝的にも公開アプリ数は昔から普通に泥と比較されてるじゃん。

あと、開発者になったら最新機種に乗り換える頻度も高くなるし4s以降とかiPadとかも買いたくなるでしょ？
iOSに関して売上は確実に伸びるしappストアのDL数も伸びる。
ユーザー的にも便利になるし誰が損するのか全然見えない

う い ん ど う ず w

>>792
WinでiPhone使ってる人のことは否定してないよ。
iOS開発したいのに手元のWinマシンでXcodeが動かないからできない、とかのたまってるあんたみたいなライト層を取り込むメリットがどこにあるのって話。
Macに乗り換えるんじゃなくて、iOS開発の時だけMacを使えばいいだけの話。

デベロッパープログラムで利益になると言っているが、Windowsで動くXcodeやiOSシミュレータの開発コストは0なのかい？
今なら本気で開発するつもりの人に開発専用のMac miniとかを買ってもらえて、デベロッパープログラムにも入って貰えるわけだから、
開発コスト、サポートコスト、どちらも削減できた上に売上まで増えるわけで、Apple的にはWindows版を開発するメリットなんてどこにもないと思うが。

現状、Xcodeはアップデートでどんどん古いMac OS Xのサポートを切ってる現状から見ても、少なくともWindowsのサポートってのはとんでもなく大きなコストがかかるから、
そんなことをやってもAppleは得しない。

Xcode for Winが出てくるようなタイミングは、iOSが凋落しまくって開発者が一切寄り付かなくなってそんな苦肉の策しかやることがないタイミングだろ。
現状、十分に活発なアプリ市場が出来上がってる以上、Windowsで開発できるようになったからってキラーアプリが増えるわけでもなし、ストアのDL数が増える要素がないだろ。

おまじないって何よ

MacでVisualStudioが出るくらいありえない

Mac買ってコーティングはWindowsのVisual Studio＋xamarinでやるのが向いてると思うぜ

MacにVSでたじゃん
VS Codeだけど

>>792
Developer Programに入るだけよりMacも買ってもらった方が儲かるだろ
>>795も言ってるようにMac miniやMacBookごときを買うのを躊躇して開発を始められないような熱の少ないライトなDeveloperは眼中にないよ
ただ作ってみました的な質の悪いアプリはストアの質も落ちるしノーサンキューだろう

　精々2万人ぐらいしかユーザーが増えないのにWindows版なんか作るわけない。
作りたきゃMacぐらい買うってw。Airを中古で買えば6万ぐらい済むのに。

　後、4ICSGBEMが言うようにアプリ開発はもはや素人の出る幕はない。

　最近は聞かなくなったが、少し前までOSXのWindows版を出せとかいう話をよく聞いた。

出すとしたら、値段的に8万円ぐらいで売らないととてもペイしない。
＋開発環境だと50万ぐらい。

なんのことはない。昔のOPENSTEPの値段やね。

>>801
＞4ICSGBEMが言うようにアプリ開発はもはや素人の出る幕はない。
プロがいきなり畑から生えてくるんですね
わかります。

あといまのモシモシゲーのアレを作ってるやつらがあれでプロって自称したら噴く

あんなもしもしゲー（）と馬鹿にすると思うが、作るのには相当の工数がかかってるぞ
普通にプロの複数人体制でそこそこの期間とらないとできない

アプリで儲けたいのならそれなりにしっかりしたコンセプトも必要だし、見た目をしっかりさせるためのデザイナーも必要だし、現状ではPRだってしっかりやらなきゃ
そもそもダウンロードにつながらない。

遊びでやってみたいなら、Androidを買ってみるか、初期投資はちょっとつらいかもしれないがMac miniとかを買うのがマジでお勧め。

実際、Windows版Xcodeが出たとして、何作ってストアに売り込むつもりなの？そんなに独創的で流行るアイディアを持ってるのかな？

Swiftのはなしをしろ

ほしかったら自分で作れよ
なに人任せにしてるんだよ

一人で作って何年かかると思ってんだよアホか

ねだるな勝ち取れ

だれも一人で作れと言ってないし
ここで意味もない叫びをするくらいなら動けば？って思っただけ
自分だったらそうするけど

>>804
そんな独創的な流行るアイデアがあればとっくに機材そろえて開発に着手してるだろうよ

やらねーくせにw

ちなみにxcodeは新mac板に専用のスレが立っているからな。

swiftもMac板にもスレあるし、そっちに行った方がいいな

今度立てるときはスレタイの先頭はSwiftか【Swift】にしろよ。
意味わかるだろ？

押し付けないでください！！！

objective-cで何の問題もないんです！

そうだな

いやスレッドの視認性の話。

独創的なアイデアがあれば、ひとりでいいんだよ。
独創的なアイデアがないから、人手だけやたらとかけた壮大な駄作ができるんだろ。
いまのファイナルファンタジーがそうだろ

独創的とかじゃなくて
あたりまえのことをあたりまえにやることの重要性。
iPhone触った後にAndroid触った時の
「なんでこんなことができてないんだ？」といっしょ。

それ君がAndoridの使い方を理解してないか、国産クソガラパゴスAndroidを見て評価してるんじゃないの
最近で言えば、AppExtensionはAndroidの丸パクリだよね
「なんでいまだにホーム画面にウィジェット置けないんだ？」って感じ

あの、ここSwiftスレなんすけど

Swiftすげー
Swift面白い
Swift最強

>>823
kwsk

Swift3.0の情報漁ってても辛くなるだけだしなぁ
あんまり表のSwifterが触れたがらないゴミプロポーザルの話でもするか？

誤訳があったらスマンな、誰も真面目に訳さないからな

SE-0062 Obj-Cのキーパスを参照可能にする
　#selectorみたいにKVCする場合、#keypathでキーパスを取るように強制

SE-0064 Obj-Cのプロパティのgetter/setterのセレクタを参照可能にする
　プロパティのgetter/setterを#selectorで取得できなかったバグの修正

SE-0066 型引数の構文の標準化
　引数なしクロージャは () -> Void なのに、引数1のときだけ Int -> Void と括弧を省略できるのは
　一貫性がないから常に (Int) -> Void と書くようにせよ

SE-0067 FloatingPointプロトコルの改良
　今のFloatingPointプロトコルはIEE754が定める浮動小数点数を操作するには貧弱すぎるので改良する

SE-0068 Selfの意味を拡張する
　self.dynamicTypeをSelfでかけるようになる、今までできなかったのが頭悪い

SE-0069 Foundationの型を値型にする
　Foundationをプロトコル拡張で全て実装しなおすのは難しいから、
　NSDateなら、Date Structと、NSDate classに分離する（参照型はNSが残る）
　その上で、Swift APIでは letとvarでImmutable/Mutableを表現する

SE-0070 Optinalのプロトコルを宣言できるのはObj-Cのみとする
　プロトコル拡張とoptinalの存在が紛らわしいから、
　@objc optionalを全てのメソッドに付けないとエラーにする

SE-0072 暗黙の型変換削除
　Swiftコンパイラのバグの温床になっていたNSString -> Stringのような暗黙の型変換を全部なくす
　必要があるならば全てasでキャストせよ

押し付けないでください！
押し付けないでください！
押し付けないでください！

訳じゃなくてどうゴミだと思うのか書けよ

SwiftのProposalなのにObjective-Cの話しかしてないのね

>>828
32行の行数制限で両方書くのは流石に難しいな、お前も煽ってないでSwiftの話をしてもいいんだぜ
基本的に記述がどんどん安全で冗長になっていくゴミ提案ばかり
逆に記述がスマートになりそうなSE-0018とかはリジェクト

あとSwiftらしいFoundationを1から作るのを諦めてるのが将来的にマイナスだと思うんだが
letとvarがあり、CopyOnWriteのSwiftでNSCopyingプロトコルなんて意味がない

>>826
SE-0062
嬉しい。コード補完も効くだろうし便利になる。

SE-0069 SE-0070
ややこしい事になってきた感じがする。

SE-0072
自動キャストなくなるのかよw
明示的にする事でコンパイラが迷わなくてコンパイルも早くなるんだろうからその点はいいけど、細かい暗黙的な変換を気にしないで書ける読めるという方向を諦めたのは少し残念

いい進化と微妙な変更と残念な退化といろいろあるね

>>831
SE-0062
クラスに対するキーパスは便利になるけど、
配列や辞書みたいな、動的に名前を解決するものはどうなるのか

SE-0069はもうちょっと全貌を纏め上げてくれないとなんとも言えないが
Immutableのlet String、NSStringとMutableのvar String、NSMutableStringにしたいのか？

SE-0072についてフォロー（？）をしておくと、String -> NSStringは現状のまま
NSStringは内部実装が多数あるから、コンパイラをよほど賢くしないとStringへのキャストに失敗する

Swift3のテーマは、Objective-Cの延命だと思う
言語仕様としての洗練はSwift4からだろう

暗黙の型変換なんて要らないだろ。
そんなもの最初から要らなかったんだよ。

暗黙の型変換→便利
明示的宣言→普通
asキャスト→ウザイ

沈黙の艦隊
進撃の巨人
暗黙の型変換

Objective-Cで十分です。

型推論でソース嫁ないだろ！ゴルァ！

Swift3終わったな

>>836
うん、みんな知ってる

Swiftの方がマスターした時の生産性が高いけどな

よく生産性高いという話聞くけどイマイチ実感がわかないんだけど
具体的にどういうところがよくなるわけ？

タイプ数が減ってる

それってxcodeのコード補完でどうにでもなるレベルだと思うけど違うんかな

var string = ""
NSMutableString *string = @"";
Xcode補完込みで減ってる

誤差だとは思う

例えば、obj-cはヘッダと実装でファイルが別々になるし、プロパティ宣言一つにしても記述量が多い
【swift】
var name: String

【obj-c】
@property (nonatomic, copy) NSString *name;

プロパティのセッタの振る舞いを変えたい場合も、obj-cだと保存用の内部変数用意してセッター丸ごと書かないといけないけど、swiftだと、willSet、didSet使って必要なとこだけ書けばいい

あと、型類推がきくからいちいち一時的な変数の型宣言しなくていいとか
【swift】
var name = "山田太郎"
let info = getInfo();

【obj-c】
NSString *name = "山田太郎":
PersonInfo* info = getInfo();

クラスや構造体の定義とかも楽

スマソ
最後の例は間違ってたw

【swift】
let info = self.getInfo()

【obj-c】
PersonInfo *const info = [self getName];

・ヘッダーファイル不要
・self ; 不要
・if let where
・function().function().function()
・よく使い回すものはプロトコル拡張で再利用性向上

また間違ったw

【obj-c】
PersonInfo *const info = [self getInfo];

・function().function().function()
[function [function [function]]]

・よく使い回すものはプロトコル拡張で再利用性向上
今までもUtilクラス等で再利用してる

微妙にObjCエアプログラマっぽい

>> 848
今時 ObjCでgetter使う奴もいまい
PersonInfo *const info = self.info;
で良いんじゃないかな、self.が必要な分、やっぱりSwiftよりタイプ数多いけど

ん？プロトコル拡張をクラスの再利用と同じと思ってるのかな
ProjectBuilder のころから ObjC 書いてる俺はエアなのかw
それは失礼しましたw

目的、実現機能は同じだろ？
文法変わってスゲーと言ってるなら、それも良し

カスタマイズポイントをプロトコルを conform してるクラス（または struct）に集中できるところが違う

コードを読む側としてはletに何が入っているのかわからないからメンテナンス性は悪い
型推論は大規模なコードを書くと、型推論がコンパイルのボトルネックになるから、敢えて定義することが多い
特にジェネリックみたいな入れ子のクラスの推論は弱い

>>853
同意
見てて明らかすぎる場合は省略していいかなという感じはしてきたが、なんかのメソッドの戻り値とかを代入されてるとなんだかわからない
タイプしたくないという要望は否定しないから、勝手にIDEで補完してくれりゃいいんだけどな

可読性のために必要と考えるなら型を明示すればいいだけ
そこはプログラマの裁量だろ

あと、enumにメソッド書けるとことか何気に便利

結局obj-cが足引っ張ってるからswiftを洗練出来ないんでしょ？

ソウダヨ

Visual Studio+C#の型推論ならvarの上にカーソル持って行ったら型がツールチップで表示されるから問題ないんだけど、Xcodeはそういうのやってくれないんだな

言語の仕様とツールの仕様は別の話

どのタイミングで型推論が可能か、ってことだから言語仕様の話でしょ？

C#のvarは使えるタイミングをローカル変数に限定してるから、その時点で型が確定している
利便性を上げるだけで特に副作用がない

Swiftはなんでもかんでもletとvarを使わせるから、
現状だと全ソースをコンパイルしないと型が確定しない

副作用？

C#のvarと、Swiftのvar、letは意味が違う
Swiftのvar, letは変数の定義だけど、c#のvarは、variant型から来てんじゃねーの？

VBのvariant型は確かに近いけど、由来は両方ともvariable（変数）でしょ
むしろletに再代入不可の意味を持たせるのはSwiftだけになると思うから、他の言語から見たら異様に見えそう

大概の言語に定数定義の仕組みがあるから別に異様ではない
型類推させる時だけvarとかつけるC#の方が異様
Swiftの var a = 10 は純粋にプリミティブなInt型だろうけど、
C#のvar a = 10は、Variant構造体とかに値を格納してそう
知らんけど

>>865
それはVBの話なんじゃないの？
あと、C++にもautoってのがあるけど、C#のvarに似た感じだし異様だとは思わないかな

>>865
いいえ
var a = 10;
はint型です

>>865
いろいろ勘違いしてるなー、C#のvarはその場合はIntに解決される
C#は基本的には静的型付け言語、後付けで追加されたdynamic型以外は静的に型が決まる

letってのは古代のBasicだと代入命令だから、再代入不可が変に思える
今後主流になるECMA7だとローカルスコープの変数にletが使われているし、混乱を招きそう
元ネタは数学（〜として定義する、をletと書く）

あと、Swiftでlet a = 10 をした場合、IntegerLiteralConvertibleに準拠した型のうち適切な型に決定される
だからコンパイル時まで型が決まらない
しかもどういう優先度があるのかはコンパイルマジック

電卓程度の小さなアプリならdidSetとwillSetの簡単な記述だけでほとんど完成したりする所は便利で使いまくってるな
頭で設計しながらリアルタイムで出来上がっていくから楽しい
delegate = self の記述は省略してもいいんじゃないかと思ってる
あとoptional関係はもっとスッキリした記述で対策できたらいいな

>>868
そういうのって変数クリックで右窓のQuickHelpに現時点で設定されてる型見れるんじゃないの？
コンパイルマジックを恐れるような作業する時はちゃんと型指定すればいいだけだし
型推論はおまけの機能ってことでよくない？
何かそこに力注ぐとガラパゴス化が進みそうで嫌だ。

結局、SwiftのvarとC#のvarは字面が同じだけで意味的には別物ってことじゃん
>>861のSwiftのletやvarがC#のvarと比べてどうのこうのという比較はおかしい

質問なんだけど、例えば

例１）
if enumValue == .None {
value_1 = inputValue
}else{
value_2 = inputValue
}

みたいなのがあったとして、value_1と2に変数の代入を振り分ける時に
value_1と2のエイリアス的なものって作れないのかな？
こんな感じで、

例２）
var areas = nil
if enumValue == .None {
areas = value_1
}else{
areas = value_2
}
areas = inputValue

『代入する側』の振り分けは普通にあるけど
『代入される側』は参照とかコピーとか理解できてなくて疑問に思った

>>864
むしろletに再代入許す言語なんてないと思うが。

>>868
letは代入命令では無い。お前はもっと勉強したほうがいい。
let束縛でクグレ。

letの起源はBASICなんかよりも古いLISP

>>873-875
・モダンなJavaScriptであるES6thだとletは再代入可、constは再代入不可という使い分け。分かりやすい
・letを代入命令として使っていたのはBASICの話（LET A = A + 1みたいな記述ができた）
そのため現在の手続き型の系譜としては、let＝代入命令の印象が強い
・もちろんSwiftは関数型のパラダイムも取り入れている、letをLISPから引っ張ってきたのかもしれない
　ただ起源ではない。pure LISP（LISt Processor）にletはなかった（そもそもリストを処理するためだけの言語）
pure LISPは1960年、ダートマスBASICが1964年（ここでletが生まれた）、
　自分の知るletのあるLispは、Comon Lispで1984年くらい

ググれで勝利宣言しないでソースを持ってきて戦おう

あと破壊的代入を許さない純粋関数型言語なら、
letで定義したレキシカルスコープの変数が再代入不可能ってのは自明の話なわけであって…

Swiftは関数型もモチーフに入れてるけれど、ベースは手続き型言語なので、
letにconstの意味を意味を持たせていることにどうしても違和感が拭えないという話をしてるだけなのよ？
variable/constantなら対義語だけど、var/letって英語としても対じゃないじゃん（笑）

おそらくこれはSwift1のころの、グローバルにジェネリクス関数を定義する、
数学的なアプローチを取ろうとしていたころの名残で、深く考えてもあまり意味はないだろうと思う

letの元ネタが数学って認めるなら再代入(再定義)できないのが本来のletのあり方ってことじゃないの

varだろうがletだろうが字面には拘らないし、letがconstとかでも別にいい。letの方が文字数が少ないから好みではあるが
ただ、グローバル変数からローカル変数にいたるまで可変変数と定数の使い分けの明確化をコンパイラの警告で徹底させているのはSwiftの功績の一つだとは思う

プログラミング作法的にまず定数ありきで、必要な時だけ変数にするべきというのを考えると
もし (定数定義の文字数) > (変数定義の文字数) だと、心理的にタイプ数少ない変数定義ファーストの癖がついてしまってよくない
定数を const にするなら 変数は variable って8文字書かせるぐらいにしないとって個人的に思う
逆に let 以外に、var より短くて気軽に使ってもらえそうな定数定義用のキーワード候補って思いつかない

可変変数はvarでいいよね
で、それに対応する定数のための記号となると、letでいいんじゃねと思う
不変という意味では、constの他に、fixとか、immutableとかありそうだけど、varの対義としてはなんかしっくりこないしね

>>878
数学のletについて言うなら、これは本来使役動詞に分類されるもので、
「aを10と仮定しますね」程度の意味で、「だからaには20は入らないです」という意味までは包含しないよ
そもそも数学の世界に代入という考え方はないからね…あくまで元ネタっていうだけ
let / var はSwiftの世界の中だけで見たときは、さっぱりした記法でいいと思う

>>881
個人的に気になるのは、let structは不変だけど、let classは単なる再代入不可の変数ということ
let束縛なんて高尚なものではない
let a = ReferenceArray()
a.append(Element())
って、気持ち悪くない？まあAppleもそれを分かっているから、クラス排斥をしたいんだろうけど・・・

どっちも３文字で短くて書きやすいし意味的にもわかりやすい
Swift の let/var という書き方は非常に良いと思う

>>882
別にクラス排斥をアップルは望んでないだろ
それを言ってるのは関数型！プロトコル指向！！と言ってる意識高い人たち

Cocoaをクラスなしで操作するIFを公式で提供する気はない
そんなことしたらObjCから叩けなくなってしまう

>>884
SE-0069読んでみ

>>882
structは値型、classは参照型という捉え方してるので、letで設定したクラスのメンバを変更できても別に違和感はないな

そんなに熱くなるような話じゃねーだろ

まぁ、まぁ、落ち着いてw

Windowsユーザーのワイ
開発できなくてしこしこjavaを使ってる模様

敷居高すぎ

>>889
何の開発をしたいの？

XamarinステマのC#推しの出番
はよこい

アプリ開発に興味があって独学し始めたんですがここ見てるとswiftってダメみたいな空気を感じます
何を勉強すればよいでしょう?

アプリの構造とフレームワークの使い方

>>892
Apple教に入信するならSwift
潰しがきくのはC#、Java
どっちつかずならとりあえず、Objective-C
敷居の高さは、
Objective-C > Swift > Java > C#
JavaとC#は敷居の高さ的には同等だけど、ツールや開発環境的にC#の方が若干低め

>>893
>>894
レスありがとうございます
参考にさせてもらいます
質問板でないのは承知の上でもうひとつ
コーディングする上で一つの機能に対していくつかの書き方があるかと思うのですが「どの書き方が良い」とする判断基準って何でしょう?可読性のみって事はないですよね
スレ違いでごめんなさい

可読性を優先するかパフォーマンスを優先するかの二択だよ

>>892
なにをもなんもiOSならObjective-C、AndroidならJava。
そして、どちらも(というより最近はなんでも)
システムが用意してる機能をどう叩くかが勉強の過半を占めるから
むしろ、そういうライブラリの使い方を覚える学習の方が大事。
逆に言えばライブラリはどの対応言語からも叩けるから
わかってる人が無茶すりゃ言語なんてなんでもいい。

swiftについて言えば言語そのものはいちばんモダンだけれども
いま、Objective-C用にObjective-Cで作られたライブラリを
Appleが改変するかどうかの段階だから、いちおう学習しながらみんな様子見中。

>>896
>>897
レスありがとうございます
大変参考になりました
皆さんと語り合えるぐらいになるのを目標に勉強します
スレチ失礼しました

>>897
並行制御の言語仕様がない時点でモダンではないかなー
async/awaitの存在を知ったら、selfが循環参照しないかビクビクしながら
クロージャコールバックヘル書いてるSwift屋は死んじゃうよ

swift屋は平行制御が swift 3 で見送られたことに大笑いして、もうそこは期待してないよ
今さらネタにもされぬ

async/awaitって実際のところ使いやすいの？
generaterとか歴史をセットで追いかけている人には使いやすいだろうけど
関数実行途中に呼び出し元に戻る挙動って、直感的かと言われると微妙なんだよね。
特に複数スレッドでその挙動された日には頭が沸騰しそう。

使いやすいよ
気軽に非同期処理出来るから多用しまくり

循環参照はweakやunowned使えばいいし
非同期処理ならNSOperationで十分やで

そこはGCDでしょ

新興言語でweak, unownedを意識させるのが古くさいとは思う
GCDもObjCではNSOperationへ乗り換えさせてるのに、移植をしないからGCDに先祖戻り

4でgoroutine相当をパクってくれると期待してる

先祖戻りって？
SwiftでもNSOperation使えばいいやん

weakとか循環参照を意識しなくちゃいけないのは並行制御云々よりARCの問題なんじゃないの？

だよね
Obj-CもSwiftも参照カウンタ方式のメモリ管理してるからしょうがない
それがいやなから片っ端からunownedにすればいい
C#はガベコレで不要なメモリ破棄してんだからそもそもメモリ管理のコンセプトが違う

どういう擁護だ、だから古くさいんだろ？
GCないRustも気合いでなんとかしてるし、時代遅れの言語/ランタイム仕様の見直しどうぞ

>>906
ヒント: Swift on Linux

>>905
>GCDもObjCではNSOperationへ乗り換えさせてる

え？逆じゃないの？

一概に古臭いともいえんでしょ
参照カウント方式の方がメモリ効率いい場合もあるし
Linuxとの互換性もそのうち使えるレベルになるんとちゃう？

>>911
古臭いといえば古臭いんじゃないかな。循環参照は防げないわけだし。
ARCが出た時は革命的だと思ったけど、循環参照も人間側が意識しなくても
防ぐ手段を用意して欲しいところ。

rust見たくonwershipを一箇所にしか持てない仕様にするとかかね。

unique_ptrを昇華させたRust
shared_ptr, weak_ptrを昇華?(強制)させたARC
在り方違うけどもうちょっと頑張ってみても良いかな
他プラットフォームへの互換性は祈ってる

参照カウント型のメモリ管理で循環参照を回避する仕組みを入れ込もうとするといろんなとこにオーバーヘッドがかかってきそう
そもそも、そこに気を回せない奴は言語問わずメモリリークおこしそう

alloc/deallocを手で書いてないプログラマは二流

そこはARCでいいだろ

Apple、次期メジャーバージョン「Swift 3.0」のリリース過程を解説、正式リリースは2016年後半予定
https://codezine.jp/article/detail/9423

>「Swift 3.0」では、言語仕様および標準ライブラリに大きな変更が行われるため、
>「Swift 2.2」とはソースコードの互換性が失われる。

>>914
モバイル端末のマシンスペックが上がっていけばまたGC的なメモリ管理に戻しても十分動くようになるかもね

>>917
現行のswiftは失敗だったということか

>>916
ARCじゃまともに参照型のメモリを管理できんから値型プッシュしてるんだぞ？

値型だとalloc,freeしないだろw
ARCポインタ、値型構造体しか使えないswift, objcでどうして欲しいんだよ

Swift言語を非公式にWindowsへ移植した「Swift for Windows」プレリリース版が公開される
https://osdn.jp/magazine/16/05/10/154000

>>922
さすがにWindowsでSwift使おうとは思わないが
需要あるのかな……

>>919
って言うか出たばっかだからまだまだ使用が変わって当然。
javaもrubyも一般的になったなと感じるまでには10年とかかかってる。

Swiftは今でさえObj-Cより生産性高いだろ
コード量も少なくすむし、読みやすい

>>924
じゃあ次回以降もまた互換性のない仕様変更があるってことか
こんなもん仕事では使えないよな

Swift Package Managerってどんなもん？
CocoaPodsやCarthageいらなくなるんかね

公式でできるのはいいことだ
Xcodeにパッケージの検索機能とかついたらいいな

生産性って、何？
今書いてもゴミコード確定なSwiftは生産性ゼロでしょ？

なぜそこまで悲観的なんだ
どんな言語でもメジャーアップデートで大幅な変更入るのは当たり前だし、Swiftはそのサイクルが今はまだ短めなだけ
多少互換性がなくなってもXcodeである程度機械的に変換してくれるだろうし
手直ししても半日ぐらいで対応できるだろ
それより、iOS自体やフレームワークの変更への対応の方が大変

目先のライトなコードの生産速度、とマジレス

>>930
＞手直ししても半日ぐらいで対応できるだろ
んなもん規模によるとしか言えない

何かあっても詫び石で済むようなアプリならXcodeの自動変換でいいよ
ただ再レビュー再テストが発生した時になぜそんなstableじゃない言語を選んだのかを上や横やクライアントに説明できるようにしておく必要はあるかな

Androidだって、WindowsだってOSやSDKがメジャーアップデートしたら、検証なしでアプリがそのままコンパイル通って動くとは普通考えないだろ
iPhoneやMacも、バイナリレベルでは旧バージョンが一応動くようにしてくれてるが、いずれにしろどんな環境でも再レビューや再テストは発生するだろ
そこが不要なのを保証してくれるのは汎用機とかオフコンの世界じゃないのか？

言語仕様のことを言ってるのか、ランタイム仕様のことを言っているのか分からんが
どちらも基本は下位互換ありで、動かない機能があったら動かないのかよwwwと笑われるのが常じゃなかろうか
Apple OSはバイナリレベルで動かないランタイムバージョンアップをすることが珍しくないから今更気にしない

Xcodeの自動変換はバカだから期待できないよなぁ
1.xの頃に比べれば多少マシになってるけど、相変わらず漏れが多い印象だ

いずれにせよ今swiftを学んでも近い将来に知識が役にたたなくなってしまうということだからな
仕事ではやってられんよ

>>935
いや、それ今Cocoaフレームワークの使い方覚えても役に立たなくなるって言ってるのと同じレベルでしょ
毎年山のように変更されるんだから
言語の変更点なんてかわいいもんだよ

>>914
でも実際のところ循環参照を意識してコード書いている奴がどれだけいるのかな。
とりあえずかけちゃうのがな〜。
swiftlintとかで警告出すようにするとかかな

>>927
たしかhomebrewの作者がApple社員になって担当してるんだよね。
>Swift Package Manager

homebrew以前は正直パッケージ管理周りはlinux系のほうが良さ気で
OSXヘイトだったけど、今はhomebrewの方がいいと思える。
各パッケージの追従が速い。golangとかhomebrewのアップデートで
バージョンアップしたんだって知ることが多いくらい

>>938
Arch Linuxオヌヌメ
というか、それフロントツールじゃなくて、サーバ側のメンテポリシーの話だろ

Swift Package ManagerのサーバはIBMだったか？
npmみたいにちょいちょいトラブルがありそうだよな
どうにもならない問題だけど、どうするのかねぇ

>>939
当然パッケージ管理に関する感想はインフラの挙動含めてのことだね。
tapすればテスト的なパッケージを取り込めるのも手軽で良かった。

linuxはdocker経由でしか使わんと思うからalpinelinuxかな。今触るとしたら。

ほんとにAppleの互換性軽視はひどいと思う
Microsoftは互換性最優先で、C#もVBも最初期からほぼソースの下位互換を保ってるし、バイナリも.NET Framework2.0以降なら問題なく動作する
Windows自体も相当低層のことしてるか、仕様外のことに依存してない限りかなりまで互換性を保ってる

Microsoft以外にしても、規模のでかい破壊的変更を加えてるのはごく少数

いままでの言語仕様がクソだったと認められるのは偉いよ
そんなクソを珍味だと崇めてる林檎信者には同情するが

>>941
それ、下位互換じゃなくて、後方互換じゃないのか？

>>943
書き間違えてた、後方互換だ

今Android開発の勉強をしていてModelにあたる
ContentProviderの勉強をしてるんだけど、
coreDataとは違うんだよね。
coreDataはdbそのままなんだけど、
ContentProviderはdbをラップしてWebAPI設計をしているイメージ。
androidの場合画面遷移も
あるuriに遷移するって感じですごくwebっぽい。

正直カルチャーショックだったんで、
iOSとAndroidの両方を開発してる人はどう考えているか知りたい。
実際どっちが開発しやすいの？
webやってる人はAndroidの方が開発しやすい？

宗教/文化の違いを理解して個々に作る
、、、のが嫌ならCordovaでもやればどうだろう
Cordovaに限らないけどウェブ屋はそっち方面に走る印象

クロージャーが深い場合に、現状では以下のような書き方してて良くない感じなんだけど、賢い方改善策を教えて下さい。

someHeavyMethod(param, completion: {[weak self] in
　if let weakSelf = self {
　　someHeavyMethod2(param2, completion: {[weak weakSelf] in
　　　if let weakSelf2 = weakSelf {
　　　　someHeavyMethod3(param3, completion: {[weak weakSelf] in
　　　　　if let weakSelf3 = weakSelf2 {
　　　　　...
　　　　　}
　　　　})
　　　}
　　})
　}
})

if letのせいでネストが余計深くなるのをなんとかしたい

if let じゃなくて guard 使え

>>946
いや。多分お互いに吸収しあって能力を高め合うのが理想。
AndroidではネットワークにアクセスするAPIはメインスレッドで実行すると
例外を吐く仕様になってる。でもそうするとネットワークアクセスの
メインスレッド実行を無くせるからiOSでも採用すべき仕様だと思う。

例えばAndroidのR.XXって形で文字列とか画像に対して自動で定数を設定できる機能があるんだけど、R.Swiftってのがでてる。
手動でenumとか切るよりずっと便利だしバグを防げる

それ、if letじゃなく多段コールバックのせいだと思うぞ
PromiseKit使ったら多少マシになりそう

そもそもifが必要なのかこれ

>>932
上やクライアントがswift指定してるという罠

Swift3で破壊的変更が起きてデスマーチになっても
上やクライアントには関係ないからな

javaやc#って破壊的変更あったっけ？
なかった気がする