Swift part10 [無断転載禁止]©2ch.net
レス数が1000を超えています。これ以上書き込みはできません。
さて、また荒らしと文字列の扱いについて談笑しようじゃないか WebAPIを叩く最小限のコードを書いています。
Terminal.Appで実行したところ、動くには動くのですが、最後のsleep文をコメントアウトすると、結果が表示されません。
sleep文はダサいので、うまい具合にbackgroundで実行中のThreadを待ち合わせる方法は無いでしょうか？なお、Swift3.0.2です。
import Foundation
var dic: Any = ["": ""]
func printJSON(_ data: Data) {
do {
let json = try JSONSerialization.jsonObject(with: data, options: .allowFragments)
dic = json
print(json)
} catch {
print("parse error!")
}
}
let url = URL(string: "http://date.jsontest.com/";)!
let task = URLSession.shared.dataTask(with: url) { data, response, error in
if let jsonData = data {
printJSON(jsonData)
DispatchQueue.main.async(execute: { print("dic = ¥(dic)") })
//mainスレッドを捕まえて実行
}
}
task.resume()
print("OK")
sleep(1) // 1秒待つ Dispatch Group使ってwaitするか
DispatchWorkItem使ってwaitするか
かな NSConditionでの実装例
ttp://swift.sandbox.bluemix.net/#/repl/58aab29626c3ba5cbe1d44ee
文字列でなんやかんや話してたエロい人たちがより良い例を出してくれると信じてる >>5
Sleep()がカッコ悪いのでsyncで呼ぶ let task = URLSession.shared.dataTask(with: url) { data, response, error in
動きがなんかおかしいと思ったら
これcompletionHandler設定できてないような 最後にdispatchMain()を追加して明示的にexit()すればいいみたい
http://stackoverflow.com/questions/31944011/how-to-prevent-a-command-line-tool-from-exiting-before-asynchronous-operation-co
#! /usr/bin/env swift
import Foundation
var dic: Any = ["": ""]
func printJSON(_ data: Data) {
do {
let json = try JSONSerialization.jsonObject(with: data, options: .allowFragments)
dic = json
print(json)
} catch {
print("parse error!")
}
}
let url = URL(string: "http://date.jsontest.com/";)!
let task = URLSession.shared.dataTask(with: url, completionHandler: { data, response, error in
if let jsonData = data {
printJSON(jsonData)
DispatchQueue.main.async(execute: {print("dic = ¥(dic)"); exit(EXIT_SUCCESS)})
}
})
task.resume()
print("OK")
dispatchMain() 関係ないけどこの外部ステートへの依存の仕方はちょっと気持ち悪く感じる
var dic: Any = ["": ""] >>9
メソッド引数の最後のclosureは（）から出して記述できるんでは？
ただ、
DispatchQueue.main.async(execute: { print("dic = ¥(dic)") })
の部分がPlaygroundでは実行されるのに、terminal.appでは実行されない？ >>10
素晴らしい！
dispatchMain()
このグローバル関数が何をしてるのか？ようわからんけど。 >>12
あらまほんとだ
ラベル関係なく使えるのね Executes blocks submitted to the main queue.
って事は、
DispatchQueue.main.async(execute: { print("dic = ¥(dic)") })
を実行しているみたいだ。dispatchMain()は。
exit(EXIT_SUCCESS)が無いと、dispatchMain()は永遠に実行待ちするみたい。
しょうが無いので、^Z + kill %1した。 while task.state == .running {
RunLoop.current.run(mode: .commonModes, before: .distantFuture)
} extension URLSessionTask {
func wait() {
while state == .running {
RunLoop.current.run(mode: .commonModes, before: .distantFuture)
}
}
}
let task = ...dataTask(...) { ... }
task.resume()
task.wait()
これならdownloadTaskとか他のtaskでも、上のextensionで1つで全部対応できていいと思う
task.wait()だけで済むから、DispatchGroupとかDispatchSemaphoreみたいにenter/leave/signalとかが各所に散らばる面倒臭さもない
DispatchSemaphore使ってsyncDataTaskみたいなのextensionに書く例stackoverflowにあったけど
これでもいいけど他のtask使いたくなったとき、そのtaskのsyncバージョンをまた別に書かないといけないのが面倒臭い
http://stackoverflow.com/a/34308158
dispatchMainはexitの置き場所で困りそう
2つのtask待ち合わせるならどこにexit置くのと考えると問題を先送りしてるだけな気がする >>4
そうそう
プログラミング言語史上類を見ない最強にエレガントでモダンな至高言語Swiftのスレだよ
Enjoy! dispatchMain
> Applications ... must not call dispatchMain()
RunLoop
> You should never try to call the methods of an RunLoop object running in a different thread
なんでリファレンスで危ないから使うなって言われてるものを優先して挙げるのか
DispatchWorkItemのサンプルはよ、一番これが「モダン」だと思う >>19
次の3つのGlobal関数内では使ってはイケナイって書いてある。
今回はOK!
UIApplicationMain(_:_:_:_:) (iOS), NSApplicationMain(_:_:) (macOS), or CFRunLoopRun() >>20
追伸です。
19のコメントは間違ってました。
アプリ内で使うのは良く無いそうです。Terminal.Appで実行する時だけにした方が良いです。 >>20
その顔文字みたいなのは何なの？...
間違いじゃないなら可読性絶望的すぎじゃね？ >>22
セレクタでっせ。
メソッド名とラベルから構成される。ラベルが省略されたセレクタもあって、underscoreで省略可を示す訳だ。
C++で言う、シグネチャだわな。 セレクタを記述できないと、Notificationを扱う事ができないので、mustな！ Overload resolver（メソッド多重定義解決）はセレクタ情報を手掛かりに、どのメソッドを呼び出すのか？解決する訳だ。
参照：C++ FAQ Objective-Cのときってもっとわかりやすい表記だったような ObjCの表記を覚えてない => ObjC使ってない
Swiftの表記を自然に読み取れない => Swift使ってない
うーん、このどうしようもない感 swiftってiosアプリ書く以外であえて選んでるって人いるの？ >>19
current threadのrunloopインスタンスのmethodを呼び出しているのだからまったく問題ないだろ… 1日経って思ったけど、 >>17 じゃtaskを待ってはいるけど
completionHandlerを待ってはいないから >>5 への回答には全くなってなかったね
忘れてくれ
completionHandlerに入った時点でtask.stateは.completedだった >>33
他に適したAPIがある上、while state がsleep 並にダサい
無限ループで状態監視とか日曜プログラマでも回避するコードだ 特に無限ループがダサいとは思わないけどな
少し低いレイヤーを意識したコードではあると思うけど DispatchWorkItem版
if #availableはguard文だとコンパイル通らなかった‥
if #available(OSX 10.10, *) {
let queue = DispatchQueue(label: "queue", attributes: .concurrent)
let printTask = DispatchWorkItem { print("dic = ¥(dic)") }
let url = URL(string: "http://date.jsontest.com/";)!
let task = URLSession.shared.dataTask(with: url) { data, response, error in
if let jsonData = data {
printJSON(jsonData)
queue.async(execute: printTask)
}
}
task.resume()
printTask.wait()
exit(EXIT_SUCCESS)
} else {
print("require OSX10.10 or newer"); exit(EXIT_FAILURE);
} スクリプトモードでメインスレッドでメインキューを待つ方法と、URLSessionで同期的に実行する方法で問題をごっちゃにしてたな
>>5 の質問の本意がどっちにあるのかわからないけど、「スクリプトモードでメインスレッドでメインキューを待つ方法」ならRunLoopを回すのが正しい回答なはず
単純化すれば
DispatchQueue.main.async {
sleep(1)
print("Hello")
}
print("Done")
これでスクリプトモードでどうやって "Hello" を表示させるか
できれば"Hello"→"Done"の順序で
この場合DispatchSemaphore等ではwaitした時点でメインキューに入れた非同期タスクに永久にたどり着けないのでwaitで固まるので誤り
待ってるのも非同期タスクも両方メインだから
let sema = DispatchSemaphore(value: 0)
DispatchQueue.main.async {
sleep(1)
print("Hello")
sema.signal()
}
sema.wait()
print("Done") >>36
ttp://swift.sandbox.bluemix.net/#/repl/58ac0f8c861c326c636916bf
一般常識として無限ループの状態監視するやつは死ねと思う
SIGNALが使えないほどの低レイヤーでそれが必要だとしてもsleepは入れる
ループ中にsleep入れないなら死ぬし、sleep入れるなら本末転倒だよねー ビジーループと無限ループをごっちゃにして死ねとかアホか RunLoopのSwift実装読んだけど酷過ぎじゃね
returnAfterSourceHandledを強制trueにして
ブロッキングキューの利点ぶち壊すとか意味分からん
別実装で書いてみた
http://swift.sandbox.bluemix.net/#/repl/58ac26055d046936d91eba1c CFRunLoopRunInMode(,,false)がポンコツでなければ
キューが空の間はセマフォのwait等と同様に
待機状態になるはずでCPUは消費しない PR出してみたら？コードがあるなら前スレのAffineTransformよりはマシなレビューが期待できそう 出すとしたら
https://github.com/apple/swift-corelibs-foundation/blob/master/Foundation/NSRunLoop.swift#L149
> CFRunLoopRunInMode(modeArg, ti, true)
ここの第3引数も指定出来て,
CFRunLoopRunInModeの戻り値をenumに入れ替えて返す
runのオーバーロード追加を要求するくらいか
とはいえコンソール系でのテスト実行以外では
UIApplicationMain等に任せる所だし放置になるのでは >>5
質問と直接関係ないけど
この文脈でのsleep()はc言語の、つまりPOSIX APIのsleep()が呼び出されると思うんだよな
無自覚にインラインCになっちゃうって、便利なのか？、危険なのか？ >>48
Thread Type Method sleep(forTimeInterval:)
こんなのもあるね。秒単位ね。 import class Foundation.Thread
RxSwiftのソース眺めてたら、見たことの無いimport文発見。
これに関してどっかに記述あるかなぁ？ import class文を使えばコンパイル時間を短縮できたり、バイナリサイズを小さくできるのかな？ import Foundation // 42500 byte
import Foundation.NSData // 42484 byte
import class Foundation.NSData // 42500 byte
let data = NSData()
swiftc -O でビルド、なんで減るんだよwww
ABI安定(予定)の4で変わるだろうし、あんま意味ないな 名前空間の汚染だけじゃないの
でも種別を明記するのは定義側がうっかり変更されたときにすぐ気づくためかな Evolution/README読む限りだとSwift 4 Stage 1に入ってるぞ？MLでも特に上がってないよな
今更リスケしても気にしないけども
それはそれとして、Stage 2が切られてStage1/2にソース互換性ないよってのに笑った
もうSwift5としてリリースすればいいじゃんよ... >>51
>import class
GRAMMAR OF AN IMPORT DECLARATION
import import kind module.symbol name
import module.submodule
ちゃんと書いてあるのね >>57
俺は職場からカキコしてる。
今はもちろん、自宅で寝る前だけど。 生みの親が辞めた言語にしがみついてる人達のスレはここですか？ カキコって何年ぶりに見ただろうか
おっちゃん、ちょっと感慨深いぜ >>62
自動制御を追求しにいった彼が
後に再登場してSwiftをDriftに進化させる王道展開を待つわ 今はなんていうんだ？
送信ボタンを押してるとか言えばいいのか？ rustライクなメモリ管理は本気だったのか
https://github.com/apple/swift-evolution/blob/master/README.md
まだ正式なプロポーサル上がってないけど、Stage1でABIレベルで仕様入れて、Stage2で文法決定なんかね >>65
Ryzenのように？
でも、彼も自動運転に行っちゃったよ shared_ptrを文法糖衣したARC同様に、unique_ptrを文法糖衣したナニカになる予感
それだけならアポーでも出来るだろうし、ObjCへのバックポートも可能だからアリだろ >>70
Ted KremenekさんがRelease Managerやってるよ。Swift4の。 至高の言語Swiftはどこまでアップデートが続くのかな
至高中の至高に達するのはいつ？ すでに至高の域には達してるだろ
今は最後のピストン運動が激しくなって絶頂に向かってるところだ 1年後?のSwift 4 Stage 2で言語仕様の破壊変更加えて
2年後のSwift5でコード下位互換を保証して
4年後のSwift6でコード下位互換をしつつ、文法のブラッシュアップしてようやく至高に至る
そこまでswiftコミュニティが死んでなければだけど、AppleとIBMは諦めろと思う
荒らしに来てる子たちはまだまだ遊べるよ、やったね 至高ってどっち向けに至高かで全然違うとは思うが、、、
FortranもCも進化をやめる気が無いのを見ると
いつまでも変化し続けるんだろうね、言語って
COBOLは知らん
c++はもはや俺には理解できない領域まで到達してるが
さらに進化を加速しようとしている
変化速度で至高を目指しているのか？ >>76
クリストスだけで先に逝っちゃったに空目した WWDC2017まであと３ヶ月ちょっとにまで迫って来た。
Swift3.1ももうそろそろXcode8.3と共に出荷かな！ Swift 4 Stage 1 すらWWDCには間に合いそうにないな
言語仕様の破壊はもう気にしてないから、betaやってた頃みたいに半年周期でリリースしてくれよなぁ 至高と究極と最強と最高と極限と元祖と本家で戦うんですね 自ら限界を定めてしまったらそこで発展は終わってしまうからな 直感的な文法と安全性を兼ね備えたパーフェクト言語のスレはここですか クラスの配列のディープコピーのやり方を教えてちょんまげ。
助けて太い人っ！ 敬虔にググりたまへ
さすれば汝に福音が齎されるであろう
アーメン ここで文字列の扱いを議論してた荒らしがrustスレに行って暇になったなぁ
文法の固定されたrustより、文法があと5年は変わり続けることが約束されたswiftの方が面白いのに...
三項演算子とか{}ブロックとか、基礎的な文法はswiftならまだまだ変わりうるぜ？ >>89
そんなんじゃ誰も釣れないだろ、、、
もっと頑張れ var a = 0
var b = 0
var array = [a, b]
a = 1
array[0] ←これを1にしたい
array[1] = 10
b ←これを10にしたい
どうすればいい？ そんなことできる言語はないと思うけど
なんでそんなことしたいの？ 複数のIntやCGFloat（クラスではない型）を、個別でアクセスと、配列化してインデックスでアクセスを出来るようにして、状況に応じて切り替えたいのです。C言語ならポインタの配列にすればよいのですが、Swiftでどうやるのかなと思いまして。
int a = 0;
int b = 0;
int *arr[2];
arr[0] = &a;
arr[1] = &b;
a = 1;
printf("%d¥n", *arr[0]); ←1が出る
*arr[1] = 10;
printf("%d¥n", b); ←10が出る なんだ、ポインター使いたいのか
UnsafeMutablePointer
とかググると使いかた出てくるよ こんな感じで
typealias IntPointer = UnsafeMutablePointer<Int>
var a_ptr = IntPointer.allocate(capacity: 1)
var b_ptr = IntPointer.allocate(capacity: 1)
a_ptr.pointee = 0
b_ptr.pointee = 0
var array = [a_ptr, b_ptr]
a_ptr.pointee = 1
print(array[0].pointee) ←1が出る
array[1].pointee = 10
print(b_ptr.pointee) ← 10が出る
a_ptr.deallocate(capacity: 1)
b_ptr.deallocate(capacity: 1) Alloc/Dealloc 使わないバターン
typealias IntPointer = UnsafeMutablePointer<Int>
var a = 0
var b = 0
var a_ptr = IntPointer(&a)
var b_ptr = IntPointer(&b)
var array = [a_ptr, b_ptr]
a_ptr.pointee = 1
print(array[0].pointee) ←1が出る
array[1].pointee = 10
print(b_ptr.pointee) ←10が出る ああ、>>99だと、ほぼそのまま置き換えできますね。ありがとうございます。 pointeeを隠蔽してこうなりました。
struct IntPointerStruct {
var a_ptr: IntPointer
var b_ptr: IntPointer
subscript(index: Int) -> Int {
get {
switch index {
case 0: return a_ptr.pointee
case 1: return b_ptr.pointee
default: return 0
}}
set {
switch index {
case 0: a_ptr.pointee = newValue
case 1: b_ptr.pointee = newValue
default: break
}}}}
var a = 0
var b = 0
var array = IntPointerStruct(a_ptr: &a, b_ptr: &b)
a = 1
print(array[0]) ←1が出ます！！
array[1] = 10
print(b) ←10が出ます！！
これにするか >>99にするか、作りながら判断します。ありがとうございました。 さすが、>>96のシンプルな表記がクッソごちゃごちゃな表記になるね
でもエレガントなのさ
Swiftだからね >>99
素晴らしい！
import Foundation
var a = NSNumber(value: 1)
var b = NSNumber(value: 2)
var ar = NSMutableArray()
ar.add(a)//, b])//(array: [a, b])
ar.add(b)//, b])//(array: [a, b])
a = 3
print(ar)
print(a)
NSNumber使えばできるのか？と思いきや、失敗！ UnsafePointer周りの公開IFは2.0から3.0までですら二転三転したから信用して使わない方が良いぞ、多分また変わる
Xcodeの自動コンバートでサポートしきれない変更だったから毎度手間だった
その覚悟をもって遊ぶなら楽しいオモチャではある
すごく日曜プログラマ向け そもそもSwift自体が意識高い日曜プログラマー向けなんだから気にしない気にしない >>78
他の言語は基本後方互換はそのままだから
別にいいんだけど
swiftは後方互換がなくなるからな
そこは根本的に違う どの言語もメジャーバージョンアップ時には完全後方互換じゃない気がするが
ただ、頻度が少ないだけで 完全広報五感の縛りは進化を妨げる
ツールでコンバートさせるswiftとアプローチは正解
さすが至高の言語swich はっはっは
マイナーバージョンアップで互換性を壊すのがswiftだ
そんじゃそこらの言語と一緒にして貰っちゃ困るぜ？ ExpressibleByIntegerLiteral使えばもうちょいシンプルにできる？ >>96
名前でのアクセスとインデックスでのアクセスを両立したいってことかな？
俺だったら、名前→インデックスの辞書を持つ専用のクラスを作る 正直Swift熱は若干冷めてきたように思う
サーバーサイドSwiftとかもちっと頑張ってくれんかなあ 2.0, 2.1くらいまではまだswiftが業務に利用できると騙された奴がいたけど、さすがにもう居ないから...
こんな不安定な言語とランタイム、信仰心/遊び心以外で使うのは無理だよ
5になってAPI, ABIが安定したら再燃することを祈ってる
>>115
swift
他の信仰言語は文法,API,ABI他諸々が下位互換を保証するフェーズにまで枯れて冷めてる >>115
はあ？
最もエレガントかつモダンでいらっしゃる超絶至高言語Swift様に決まってんだろ
馬鹿なの死ぬの？ ブームは確かに去り始めてる気はする。
けど言語はまったく枯れ初めていないっていう現実。
ところで今年のtryswiftはどうだったの？
相変わらずswiftと関係ない話題ばかりだった？ >>115
Scala, Groovy をミックスした、Android用のJVM言語、Kotlin 3への移行がダルすぎる
みんなもうやったんだろうな、、
2、3と共に生きるわ RxSwift3.20に付属のPlayground重すぎ。特にCombining_Operatorsが。
マシンパワーが不足なのか？特にCPU Power。メモリ搭載量(16GB)には問題無いみたいだが、IvyBridge世代のcore i5 2coreには辛いのか？
同じ感想の人入れば、レスお願いします。 RxSwift3.2.0を動かしてます。SubjectはObservableかつObserverだと言うので
次のコードをiOSアプリ内で動かしてみました。
import RxSwift
let sb = BehaviorSubject(value: 100)
let v = Variable(2000)
_ = v.asObservable().bindTo(sb)
print(v.value)
_ = sb.subscribe{print($0)}
// 2000
// next(2000)
このコードがPlaygroundで動きません。ObservableはbindToメソッドなんて
持ってないよ！と怒られます。どうやれば、Playgroundで動かせますか？ ちなみにmacOSアプリ内でも動きました。
Playground内だけで動きません。ウェーン！ >>126
import RxCocoaを追加すれば動いたよ >>128
まじっすか？
Playground execution failed: error: MyPlayground2.playground:1:8: error: no such module 'RxCocoa'
import RxCocoa
当方では、moduleを見つけてくれないです。 もしやRxCocoaをbuildしないといけないのか？もう一回！ みなさん、あんがと！
bindToが動きました。
no such module when openning playground
でヒットしました。 RxCocoa-iOSのbuild時間 46.837sec
でした。
結構、時間かかります。 >>133
Java, C++には遠く及ばないんだよねぇ。
おれ、Java嫌いなんだよねぇ。けど、TIOBE Programmer’s Indexでは1stなんだよねぇ。 Swiftの敵は、Java、C++じゃなくて、Objective-Cだから っていうかObjective-Cを初めて上回ったっていうのが驚きだわ
感覚的にはObjective-Cはとうの昔に終わってて
もうみんなSwift使ってるとおもってたんだが ん？
記事には、「2015年12月にはObjective-Cを初めて上回り」
って書いてあるが
文盲かな なぜSwiftを使うのか
それはApple様御用達だからである
つまり超絶至高言語であることが生まれながらにして確定している言語
後光なんかも射しちゃってるレベル ちょいちょい順位ネタ貼られるよね
そんなに「宣伝」しないといけないほどひどい言語なの？Swiftって 俺にとってはSwiftはRubyの皮を被ったC++
Generics標準ライブラリが充実してるのがGood。
文字列Stringが最初から標準ライブラリに入ってるのもoK. >>143
言い方悪かった。
文字列の扱いがStringに統一されているのが良さげ。
参考：Visual C++
char 型のナロー文字リテラル。たとえば 'a'
wchar_t 型のワイド文字リテラル。たとえば L'a'
char16_t 型のワイド文字リテラル。たとえば u'a'
char32_t 型のワイド文字リテラル。たとえば U'a'
もう、ワケワカメ！
このほかにもCStringとStd::Stringもある。 C言語ってやっぱり高級感のバランスがいいと思うわ
で、その良さをそのままにオブジェクト指向を導入したObjective-Cは...
おっとここまでにしておかなくては >>144
C++11でstd::stringが標準ライブラリに入ってるんだよなぁ
未だに拡張文字列ライブラリしか見てない時代遅れ乙 >>142
Rubyとは普通に違う気がするが…
Groovy（Kotolin）が見た目の文法は一番近い
Swiftは関数のラベルのところが独特 >>147
C++98な
VC++6.0のときからある
当時はTCHAR対応でtstring使ってたけど collection.map { ..... }
の書き方は
collection map {....}.
ってかくsmalltalkの書き方の真似だよ。
rubyでは{...}がオブジェクトじゃないからこうするんだけど
swiftは{...}がオブジェクトだけど関数の()が省略できないから
という理由でこうするのだろうね。 >>152をもしよむには、そこの間に:忘れたから各自補っておくように。 >>152をもしよむには、Smalltalkのブロックが [ ] になってないからこれも各自脳内置換するように。 >>152
それ単にブロックを受け取るキーワードメッセージを一番最後に持ってきてるだけでしょ。
ブロック引数を特別扱いして不完全だけど有用な文法を作り出したrubyが真似たと言うにはちょっと… >>152
Swift や Ruby のメソッド map に相当する
Smalltalk のメッセージは collect だよん
まとめよう
[Swift]
・collection.map({ ..... }) // 一般的(常識的？)な書き方
・collection.map() { ..... } // クロージャを引数リストの直後へ移動できる
・collection.map { ..... } // さらには丸カッコ () も省略できる
[Ruby]
・collection.map(lambda { ..... }) # Ruby だと一般的ではない
・collection.map() { ..... } # ブロックを引数リストの直後へ移動できる（ブロック付きメソッド呼び出し）
・collection.map { ..... } # さらには丸カッコ () も省略できる（これが普通の Ruby らしい書き方）
[Smalltalk]
・collection collect: [ ..... ] "書き方はこれだけ"
たったこれだけで Swift の Tailing Closure は「smalltalkの書き方の真似」って言い切っちゃう>>152さんて素敵(棒 よくわかんないけど
だからSmalltalk系譜のObjCは最高！Swiftはクソ！！
っていう荒らしの流れでおk？
swiftがperlとpyhtonとrubyとphpとjavaとc/c++とkotlinとgoとrustとetc....に似てるって
swift betaが出た当初から言われてたのに「SwiftはRubyの皮を被ったC++ 」とかヘソで茶が沸くよね
あっちこっちの言語から文法パクってるのに自分が知ってるRubyだけしか注目できてないだけじゃねーかw rubyの言いたいことはメソッドの定義をメソッドの使用する形で書けるようにするって
事で、
smalltalkの言いたいのはオブジェクトの定義をオブジェクトにメッセージを送る形で
書きたかったということだから発想は同じ。
例えばC言語だと定義はint f(){}の形だけど使うのはf()の形だから同じじゃないからね。 >>157
せっかくSwift と似ている言語として「perlとpyhtonとrubyとphpとjavaとc/c++とkotlinとgoとrust」を
挙げてくれたのだから、各言語ユーザが自分の知っている言語に注目して、似ている所をカキコすれば
いいのではないかと思われ
たとえば、もし仮に Swift で内包表記が採用されていたなら、
「Swift は Pythonから内包表記をパクった」と主張できるよね
あるいは「Swift の Tailing Closure と似ている言語は XXX がある(Ruby だけじゃない)」といふ
意見が出てくれれば嬉しい限りですねえ Haskellにも似てるらしいぞ
CPUの歓声が聞こえてくるところが >>151
その程度の類似でRubyの皮を被ったとは言わんだろ >>156
どうてもいいけどRubyはcollectの別名がmapだよ
普通はmapのほうを使うけどね 他の言語の影響受けてるのは明言してるんだし
パクッてオリジナル主張してるわけじゃないから何に似てようが別に良くね
話の発端っぽい>>142も「俺にとっては」とあるから
単に当人が知ってる範囲内での感想だろう 別に良いよ、Swiftの世間話として談笑してるだけだよー
SwiftはPythonから関数引数の順不同指定可をパクった
・・・が2.xのいつぞやのタイミングで仕様ドロップと相成って悲しい
確かにSwiftで使うメリット少なくて利用者いなかったかもしれんけど、わざわざ実装したのに勿体ない >>166
名前付き引数の順不同化はSmalltalkのメッセージ式を見たら誰でも最初に思いつくアイデアだけど
似たようなObjective-Cのやり方を内部的に引きずっていたらきっと難しいだろうね
ちょっと試すくらいなら簡単だけど、すぐに破綻をきたす >>165
話の発端「Rubyの皮」、の発言人です。
Pascal, Clang, Fortran, Lisp, Ruby, Visual Basic, C++を触ってきた経験からの
感想です。Rubyの皮を被ったC++ってのは。
Swiftはいろんな言語の影響を受けてる事が判りました。
今はJavaScriptを触りたいけど、時間が無い。 >>171
プログラミング言語の黎明期に名を馳せた大御所だから
言語の歴史と発展を語る上でその存在は無視できない >>173
では、その大御所は現代のプログラミング言語にどの様な、影響を与えているのでしょうか？ 影響というより、その冗長性と非モダンな特徴からくる反面教師としての側面の方が大きいかな
COBOLを知っていないと実感をもって指摘はできないだろうけど >>176
まあまぁ、そんな過激な事言わずに！
ってか、ボキャ貧すぎる。 C言語系やっていてK&Rを知らないってどういう事？ >>179
日本人やってるけど原文で源氏物語スラスラ読める奴少ないだろ？
既に古典なんだよ スラスラは読めないけど、作者と大体のあらすじは知ってるわな >>183
草書は無理だけど行書は読めるんでない？ 文法もわからんしAPI仕様書もない、ムリゲ
しかし、日本語の大御所で基礎の基礎だから読めないヤツは日本語を話る資格ないのか
これからは日本語でおkとか言えないな、、、 コンパイラなんてそんなもんだよ
ソースが同じでもテキストフォーマット変わればコンパイル通らないし
同じ言語でも世代が違えばコンパイル出来なかったり動作が変わったりする >>193
Ruby1.8, 1.9しか知らんのだけど、今時の2.4ってのは全然動作が違うのかね？
osx El CapにはRuby2.0搭載なので、極タマに使ってみて、あんまり変化の無い
事に安心してるんだが。 >>191
「日本語でおkとか」の「とか」は、「日本語でおk」以外の何？ とか
1.
《副助》例をあげて並べるのに使う。 「Ａ―Ｂ―の記号」
2.
《普通は下に「言う」「聞く」などを伴って》 《連語》内容が不確かであることを表す。 「橋沢―いう人」
>>191の場合は、「2.」の用例だろ
つまり、
「日本語でおk」だったか、「日本語でOK」だったか、「日本語でおっけー」だったか不確かだけど、そんな風な言い方
ってこと >>196
内容が不確かな事を書かれても、不確かなのだから、何を書きたいのか解らないよ。 >>197
>>191の言いたいことは、”日本語でおk”のネタさえ知ってれば通じるだろ
通じなかったとしたらネタを知らないか、アスぺなだけだろ >>199
この人はこのスレに住み着いて「とか」だけに反応する可哀想な人だから
みんなでとかとか使いまくってもっと可哀想にしてやろうよ(いじめの提案)
>>197
不確かであることを明示して話を進めることはよくある事だよ
主に明確化に意味が無い、あるいは主題を明確にするために枝葉部分を意図的に明確定義しない、などの用法がある >>191のとかは不相応の程度を強める際の「なんて」と可換なニュアンスだろう
例 ハゲとか無理 とかに無理やり絡めると
省略あるいは不明確を示すとかはワイルドカードなんだと思う
とりあえず早い事perl like構文で使える正規表現をサポートしてほしい
Swiftのガッカリポイントの一つがまだ純正で正規表現が使えないというところだったから >>204
String#range(of:options:range:locale:)
options のところに .regularExpression を使えば、searchString で正規表現を利用した文字列（例えば “2ch+*" とか）が使えます。 typealias String.CompareOptions = NSString.CompareOptions
に注意ね。 >>205
うん、しってるんだけどさぁ、これってNSStringにブリッジしてそっちのregex使ってるんじゃなかったっけ？
内部的にutf16になっちゃうので使いにくかった気がする
Swift2の頃の記憶だからSwift3では違うのかな？
Swiftではregex使わないようにしてたので、久しぶりに使ってみるかな？
それと、perlみたいにregexの結果をイテレートしてとか
そういう使い方したい import Foundation
let str: NSString = NSString(string: "Charlie Brown")
let a:NSRange = str.rangeOfString("Brown")
print(a.location)
print(a.length)
print(NSNotFound)
var ar: NSArray
do {
let reg: NSRegularExpression = try NSRegularExpression(pattern: "Brown",
options: NSRegularExpressionOptions.UseUnicodeWordBoundaries)
let str0 = str as String
let match: NSTextCheckingResult? = reg.firstMatchInString(str0,
options: NSMatchingOptions.ReportCompletion,
range: NSMakeRange(0, str.length))
print(match)
print(match!.range)
} catch {}
ちょいと前に保管したsnipet >>208
さんきゅ
あとで試してみる
しかし、やっぱりperl並みのお手軽さが欲しいところ 少し前のDev MLで正規表現を言語仕様に組み込む話題があったような
あって困るものじゃないから入って欲しいね 議論はあったけど4には入らんと思う
> Addressing Regexps in Swift proper is out of scope for Swift 4, because
> there's simply no time to design and add the necessary language features. Obj-Cもそうだけど、Swiftで正規表現使おうとするたびに、使い方をググってるわ
Perlだとすぐに書けるんだけどな >>213
ABIって見るたびに、なんの略だったっけ？となる。
BI = Binary Interfaceだよね？
What does “A” stands for? >>215
"A" for Application APIの派生
ソースレベル互換→バイナリレベル互換 なかなかAPIとABIとシステムコールとライブラリとフレームワークという言葉ををきちんと分かった上で使い分けるのが難しいんだよね
うちの若手とか
>>213の文脈だと
以前からあるライブラリとかと再コンパイルしなくてもリンク出来る
ってのがABIレベルでの互換性だろうね システムコールは置いといていいでしょ
普通の開発者は直接的には使わないんだし これと言ってることが微妙に違うのはInfoQの情報が古いのか、こっちの更新が遅れているのか
https://github.com/apple/swift-evolution/blob/master/README.md
はよABI安定させてlibSwift.soをiOS, macOSのシステムライブラリに保存してくれよなぁ
Swift 3でABI安定させるって理想だった頃はその構想だったのかもしれんが、ABI安定時期が不透明な今はもう諦めてるのかもしれん >>219
いやさ、printf()で済むところをwrite()とか、put()とか使いたがる人が居たりするんだよ
ライブラリ関数とシステムコールの違いが分かってないのよねん
説教したくなるのをグッとこらえて、システムコール使うと遅くなるしメンテナンスが大変になるんだよと言ってもなかなか納得してくれない Objective-Cでおｋ
以上。
おつでした。 >>221
printf()もシステムコール使ってるよ
write() put()はシステムコールでなくラッパー関数でライブラリの一部
遅いのはシステムコールやチェック処理の回数差でバッファリングに起因する >>221
システムコールって遅いの？逆なんじゃない？
つまり、ライブラリ関数より早い。
だって、ライブラリ関数はシステムコールのラッパー関数なんでしょ？
俺、arc4random_uniformとか、atofとか使いまくってるんですけど。 >>223
write()ってのは、何を指しているのでしょう？
ライブラリの一部というのだから、
FoundationライブラリString#write(to:)の事でしょうか？
なら、printfよりも遅いですよね。
put()はなんの事でしょうか？ >>224
システムコールは特権レベル変更に伴うコンテキストスイッチなどのオーバーヘッドのため
ユーザーモードで完結するものより遅い
atofはシステムコールしない、arc4random_uniformは再シードのときだけシステムコールするようだ
>>225
>>215-219はSwiftやiOSに限らない一般的な話, >>221,223はC言語標準ライブラリまたはPOSIX
putはputsやfputcなど
通常のプログラムからラッパー関数はcdeclなどで呼ぶ
ラッパー関数はシステムコール番号などをレジスタにセットして
int 80hやsyscallなどのCPU命令を実行する 長々書いたけど swiftdoc.org やAppleの開発ドキュメントを
見てたら多分支障無いから気にしなくていい まさかこのスレにシステムコールのオーバーヘッドを気にするようなスピード狂がいたとは 1,000バイトの読み書きをするのに、1バイトずつ、
syscall * 1,000回すると遅いから、
ライブラリ内でバッファを確保(バッファリング)して、
1,000バイト貯まったタイミングで、syscallを1回だけ呼ぶと、速い Dispatchの良いドキュメントってありますか？英語でもいいです。mpiのparallel forと同じようなことがしたいんですが、よくわからないので勉強したいので >>231
Apple Gudes and Sample Codeで探せば！
Concurrency Programming Guide
とかヒットするけど。
Dispatch Queues, Dispatch SourceのSectionを参照。 システムコールのオーバーヘッドを気にするような人がSwiftのようなモダンな高級言語を
使うとは胸熱だな
速度をちゃんとコントロールしたいならObjective-Cじゃないと無理だろ... ObjCもlibobjc.soとかのランタイムを食わせないと動かないからダメだろ
Swiftよりはランタイム総容量は小さいけどObjCにもランタイム/ラッパー関数は必要なんだぜ？
システムコール呼び出すC関数呼ぶだけならSwiftでもできるから同じ土俵 system callの呼び出し履歴を表示する、dtrussってコマンド見つけた。
trussのdetails版らしいけど、trussってなんの略だ？ trussはmanのsection 1にあるはずなんだけど、documentが、ない。
なぜだ？ truss = trace user signal and system callかな？ >>234
>システムコール呼び出すC関数呼ぶだけ
C言語に頼るwithout CなSwift 文法はwithout Cだけど、機能はwith CのSwiftすごい！！
Modern Objective-Cとかいう微妙に時代遅れなモダン言語(笑)とは違うな Swift：「文法はwithout Cだけど、機能はwith CのSwiftすごい！！」
C：「それじゃあ結局のところSwiftは文法的な見た目をモダン（）にしただけの言語ってことになっちまうじゃねぇか...」
Objective-C：「」 つまりインラインでC言語が書けるObjective-Cが最強ってことだな。
SwiftもC言語埋め込めるようにすれば最強になれるで。 じゃあ、swiftにObjective-Cを埋め込めれば、真の最強じゃね？ ソースが汚くなるから
王室に乞食を招き入れるわけにはいかんだろ >>242
文法はwithout Cで機能はwith CのSwiftの最強
何が不足なのか分からんぞ？
ObjCに比べてランタイム容量がアホほど大きいデメリットは分かる >>242
まあObjective-CはCのスーパーセットだからな
Cそのものを含んでると言っていい
CでできることはObjective-Cでも100%できる 俺はObjective-Cで、かつ、省略しない方が好き。
Swiftは、なんか、いろいろ中途半端。
あと、省略可能なのは良いけれど、省略した時にどうなるかを、考えなさすぎ。
省略時の動作は、最終的にコンパイラの実装依存になる。
よってコンパイラが変われば、全く期待した動作にならない場合だってあるんだよ。 Swiftに、省略時の曖昧な動作なんてあったっけ？ >>242
Swiftでも直接Cの関数呼べるけどなんか問題ある？
このスレでも少し前にdup2()呼ぶサンプル書いてる人いたよ
個人的には
"C":{}とかで囲んで明示する必要がいるくらいには敷居を上げておいて欲しかった
今だと普通に呼べすぎて、swiftの関数なのかCの関数なのか見分けがつかない >>250
型推論の事言ってんじゃないか？
別に省略してる訳じゃないのにね。
あるいは、syntax sugarの事かも。
Array<Int>を[Int]とか書いたり。 Swiftってザ・意識高い系って感じの言語だな
C言語の関数呼べるようにする必要ないくらいじゃないと言語とは言えんし Bridging Headerもmodulemapも言語の機能じゃ無いよ without Cを謳っておいてCの関数を呼び出す
仕組みを用意してるのって滑稽だねってだけだよ >>254
比較対象がVM言語やインタプリタ言語かよ
意識低いなw without C を謳うのは建前
でもcが使えちゃうのは本音
日本人ならわかるだろ？ gccがgasコードを吐くように、swiftもObjCコードを吐けばいいんじゃね？ｗ >>260
それは難しいだろう。
associatedtype付きのprotocolとかObj-Cに移植できるの？ gccがgasコードを吐くように、clang/swiftcがLLVM IRコードを吐く件
>>251
Swiftコード中に書くC, ObjC関数は、.swiftヘッダファイルに同名で再定義されたswift関数だから見分けつかない
Swiftフレームワークライブラリの中に入ってる.swiftヘッダ見るとC,ObjC,Swiftの全ての関数が同列に並んでてこんなことしてるのかよwwwって笑う JavaのJNIだとCを呼び出すための敷居が高すぎるんだよな
でもswiftだと敷居が低すぎる
なんてワガママな俺 C言語の関数呼び出さないとやりたいこと出来ないわけ？ やりたいことを出来ないんじゃなくて、>>238のように出来ることを煽りたいんだと思う
それが煽りになってるのか分からんけど
最初は(システムコールを扱う時に)SwiftだとObjCほど性能でないwwwって煽ろうと思ったら同レベルで引くに引けなくなった感じがする
単純にSwiftランタイムのばかでかさに依る性能劣化を煽ってればその通りなのにね
ランタイムのロードとか関数マップテーブルからのAPI検索とか、システムコールだと差分ないけど一般利用時に性能悪いのは必然だもの Swiftでないとダメな5つの理由
とか誰か書いてよ 1.学習コスト
2.生産性
3.スタイリッシュ性
4.流行
5.信仰心 >>264
さあ？
あなたの作るプログラムで必要であれば必要だし
必要でないなら必要ない
うちの場合OpenCV使うのにC++ブリッジ使ってる
あと、無限ループで延々九九と答え吐き出すコンソールアプリ作っておいて
Ctrl+Cを押されたら「知るかボケ！忙しいんじゃ」と吐き出して、そのまま無限ループを続けるプログラムを作りたかったら
俺はSwiftだけで書く方法を知らないのでCの関数(と言うよりはPOSIX API)を呼び出す
どうして全部Swiftでできるようにしないのか？と言う問いに対しては
Javaプロジェクトが一つの答えだと思う
OSのAPI層までを言語と標準ライブラリに取り込もうとする意欲的な試みは
20年以上かけてある程度成功したが、柔軟性を失わせる副作用と言語の肥大化をもたらした
そしてJavaからCを呼び出す仕組みであるJNIは未だに必要とされている
全部をプログラミング言語に取り込むのではなく既存の仕組みとうまく連携するのがバランスの良いとの判断なんじゃないかな？ swiftは初めからjavaのようなマルチプラットフォームを目指しているわけでもあるまい Floatを引数にとる関数で、その引数の場所で(1+n)とかやると、
Binary operator '+' cannot be applied to two 'Int' operands
ってエラーが出て嵌った。
http://stackoverflow.com/questions/40557214/swift-operator-throwing-error-on-two-ints
エラーメッセージが不親切過ぎる。 上のリンクでは
Binary operator '*' cannot be applied to two 'Int' operands. Expecting two 'CGFloat' operands.
ってエラーメッセージの方が良いと書いてるけど
Binary operator '* -> CGFloat' cannot be applied to two 'Int' operands. Expecting two 'CGFloat' operands.
だと、まだ分かりやすかったと思う。 >>266
「Swiftでないとダメな5つの理由とか」の「とか」は、「Swiftでないとダメな5つの理由」以外の何？ Objective-Cこそ王族の言語(信仰心
>>266
ダメな理由なら3つほど
1. 小さなランタイム(笑)
2. 頻繁に破壊される言語仕様
3. 不完全なエコシステム(ビルドツール)
これらはメリット/デメリットが双方あるものじゃなくデメリットしかないから煽ってもおk
この辺はswiftユーザはもう諦観して苦笑しながら使ってるデメリットだけども >>273
お、久しぶりに出てきた
全部の「とか」に反応するわけじゃなくて
選択的に反応してるのか？
しかしその選択基準がまだよく分からないな >>269
うん、
マルチプラットホーム対応を言語レベルでは行わない選択をした=実行環境ネイティヴ(多くの場合はCで提供されている)とのインターフェースが必要
だと思ってる
without CなのにCが必要wwwって煽ってる人は
言語仕様とネイティヴインターフェースを混同しているおバカな自分をアピールしたいんしゃないかな？ >>269
Multi-platform目指してると思うよ！
Linux, macOSとで動くし。
Windowsでもそのうち動く様になる。bash, vimが動く様に。 >>270
A + BでそのError Occuredの場合、
大抵は、
Int(A) + B
ってするとOK >>278
動く、使える=swiftがswiftプラットフォームとしてマルチを目指しているではない >>278
cygwinポーティングはとっくに公式にマージされただﾙﾙｫ
Androidでも動くしコミュニティの愛すべき馬鹿どもは頑張ってる
>>279
それ、Int(A)がキャストじゃなくコンストラクタ呼び出しで生理的に気分悪いよな
どこまで最適化走るか不明瞭だけど普通に考えて性能悪化を手助けしてる オプショナル型ちょ～便利
型類推もちょ～便利
文末にセミコロン不要なんてサイコー
letとvarの使い分けがありがたすぎ
switch文が強力すぎて鼻血でたー
enum構文がおいしすぎてよだれ出るぅ
Playgroundが便利すぎぃ
他にもまだまだたくさんよりどりみどりぃ >>281
キャストとは、Superclassを同じくするインスタンスどおしの型変換。
IntとCGFloat間でキャストできる方が気分悪い。 >>278
あ、ごめん、スレチかと思って説明しなかったんだけど、
Javaはバイナリレベルでのマルチプラットホームを旗印にしてたんだ
"Write Once Run Anywhere"をスローガンにして
つまり一度コンパイルして作成したアプリとかは、macでも、winでも、unixでも、携帯でも、再コンパイルすら必要なく同じ動作するよ！って
そのためにAPIやABIなど今までOSの役割だったところをJavaという仕組みの中に取り込んでいった
もちろん、そんなにうまくいくはずもなく"Write Once Debug Everywhere"と揶揄されることになった
それに対して伝統的なUnix系の考え方は、再コンパイルして動けばオッケー
動作が違う？OSとかの環境が違うんだから当然だよね、ソースでifdefしよう！
って感じのマルチプラットホーム
これですら、PosixやSUSとかの活動によるAPIや実行環境レベルでの統一化や
gnu automakeなどによる実行環境とビルド環境の調査とそれに対応したビルド
などでかろうじて維持されているレベル
C言語とかで書いたプログラムがmacでも、winでも、Linuxでも動くというのは
言語がマルチプラットホーム対応しているわけではなく、後者の意味でいろんなプラットホームで動くようにプログラムやビルドシステムを書いているから
Swiftも今の所後者に属してると思うよ >>283
お前それプリミティブ型のintとfloatでも同じ事言えんの？
基本的な数値型をプリミティブ型として一般的に提供しないSwift
プリミティブ型ではなく構造体型で全数値型を提供する意義は分かるが性能劣化してるんだよなぁ >>284
THX
Single UNIX Specificationってのがあるのね。 なんでここCのシンタックスを外したことをwithout Cって言ってるのに
without CつったらCの機能が呼べないようにならないとおかしいだろ？
とかとんちんかんなこと言う奴しかいないのん？
ラトナーが草葉の陰から泣いてるぞ >>285
Swiftの高速演算に対する思想。高速演算必要ならClangで書いてね。Frameworkって仕組みを用意するから、Clangのソースをemmbed inしてね。って事なのだ。例：RxSwift/RxCocoa/Runtime
高速演算したけりゃ、その部分をClangで書いてSwiftから呼べば良い。 >>285
@_transparent付きで中でビルトインの変換呼んでるだけだからCやC++と比べても性能劣化なんて皆無だと思う
実際にIR見ても別に無駄にジャンプしたりしてない
素でsitofpとかしてるだけ
ナローイング変換はprecondition入るけどそれも最適化されるし Clangっていうとコンパイラしか思い浮かばないんだが > Frameworkって仕組みを用意するから、Clangのソースをemmbed inしてね。って事なのだ。
Swift Package Managerがクソな完成度でSwift Framework LibraryにC言語のソースはembed inできないんだけど...
まぁそもそもアレはFramework Libraryを生成するコマンドとしても成り立ってないから論外なのかもしれんが
Swift公式として真っ当な技法を提供してなくて、バッドノウハウとしてRxSwiftやRxCocoaがやってることをやれってことなんだろうな(ｳﾎﾞｧ >>284
「一度コンパイルして作成したアプリとか」の「とか」は、「一度コンパイルして作成したアプリ」以外の何？
> macでも、winでも、unixでも、携帯でも
macはハードウェア
win、unixは、オペレーティングシステム
携帯は動詞
「C言語とか」の「とか」は、「C言語」以外の何？ 一度コンパイルして作成したアプリとか
一度コンパイルして作成したアプレットとか
一度コンパイルして作成したサーブレットとか
C言語とか
C++とか
Pascalとか >>293
NG: macはハードウェア
OK: OSはmacになり、ハードウェアはMacのまま
揚げ足取るのって楽しいの？
アスペなの？ >>293
この場合のとかの用法は明確に定義しないことを明示するための、、、、、、
とかではなくて、
説明しよう！(富山敬風)
ターゲットが特定のキーワードに高確率で定型のレスをつけることを利用して
ターゲットのレスを意図的に引き出そうとする
ドメイン特化キーワード、いわゆる釣りワードである
(↑これが言いたかっただけなのだ)
釣りとわかって付き合ってくれてありがとう >>283
え、そうなの？
swift界ではそういう定義なん？ アスペとかと遊ぶためのキーワードに爆釣(釣り糸タラー
>>290
結構冗長処理の差分があるけど、どんなオプションで吐いた？
% swiftc -S -O test.swift
--
import Foundation
func main() -> Int {
let a: CGFloat = 1
let b = Int(a)
return b
}
% test -S -O test.m
--
int main() {
float a = 1;
int b = a;
return b;
} スマン、後者のコマンド間違えた
% clang -S -O test.m
で読み替えて >>300
当たり前だけどそのコードじゃ、どっちも意味のないaの行は消えて直接整数の1を置くだけのコードに最適化された
[swift]
func foo(f: Float) -> Int {
let i = Int(f)
return i
}
[c]
int foo(float f) {
int i = f
return i
}
これで見ればfloat→intの変換はどっちもcvttss2siの1ステップになった
Swiftの方は-Oだとcvttss2siの前にprecondition由来のコードが残るけど-Ouncheckedならそれも消えて完全にCと同じ var i = Inf(f)
じゃないと
int i = f;
と等価じゃなくね？
んでもってCではセミコロンいるけどね 数値の型変換がイニシャライザなのは良いけど
情報欠落するケースかどうかが変換箇所のコードで分からないのは好きじゃない
Int32→Int64のような拡張でも暗黙変換しない方針を選んだのなら
逆に縮小をラベル付きにしてコードから判別出来るようにして欲しかった
Int32.init(_: Int16)
Int32.init(narrow: Int64) // init(_: Int64)
Int32.init(truncatingBitPattern: Int64)
例えばC#では拡張は暗黙変換、縮小は明示キャスト必須になっている そうだよな、CでもC++でもSwiftでも
自信を持ってキャストできた試しがない
何が起こるキャストなのか詳細に分かると便利だね >>282
こん中だとけっこう感動したのは
＞switch文が強力すぎて鼻血でたー
これだな
複雑なif文の入れ子がかなりシンプルにできる
日常的に一番お世話になってるのはオプショナル型
ヌルポ踏むことが無くなったかな >>305
おれの得意なXXXと、どうして違うんだぁぁぁぁ。
よくあるよね。 >>308
得意かどうかや違うかどうかは関係無いよ
考慮された上での仕様かどうかという話
数値型の暗黙変換を無くしたことは前進だと見ている
しかしその結果、拡張変換の構文が縮小変換に追いついてしまい
非対称性による利点が失われてしまった >>308
まさにこれ
Perl風の正規表現サポート構文を全言語で採用しないなんて信じられない！
文字列処理なんてプログラミングの基本中の基本でしょ！
一文字ずつの処理をプログラマが書くなんてあり得ない！！
待ってるぜSwift5 >>307
1.x初期にif letを子入れしてた時はシネと思ってたけど今のif, switchは便利よな
パクリ元と思われるrustより使い勝手よい >一文字ずつの処理をプログラマが書くなんてあり得ない！！
いや、じゃあ誰が書くんだおｗ
アプリプログラマ、だけな、それ言うの
あと、1文字ずつの処理「も」かける、というのが便利
とりあえず「デフォ」を便利にして欲しい 勉強で単純なカメラアプリを作ってるんだけど、せっかくだからフレームとサイズだけはオリジナルにしたい
でもやり方がよく分からなくて困ってる
良ければ誰かヒントをくれないだろうか UIWindowクラスでググったら？
と思ったら、すぐ見つかった。
“UIImagePickerController cameraOverlayView”でググレカス
http://chicketen.blog.jp/archives/7404852.html >>313
＞いや、じゃあ誰が書くんだおｗ
＞アプリプログラマ、だけな、それ言うの
もちろん、カーネルプログラマや、ライブラリプログラマの皆さんの成果を美味しくいただけるという前提の話です。
アリガタヤ～
なんか、入力が文字列だと、自分でプログラム組んで処理する以外の方法を思いつかない人が多くて困るのだ。 >>315
ありがとう
それを足がかりに頑張ってみるわ let isFool = false
let YouAreFool = !(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!isFool))))))))))))))))))))))
今年のグーグルのエイプリルフールネタはイマイチだね 過疎りすぎだろ
お前らやる気あんのか
let π = Double.pi >>321
>let π = Double.pi
おぉー、動くね！ そんなのに驚かれても...
とっくの昔にJavaでも動くけどな... >>323
俺、変数名に英数記号以外が来ると、拒否反応を起こす。
古いのかなぁ？俺って。
だから、let pi = Double.pi
が好みなんだけど。 >>324
普通は使わない
Javaでもutf8対応を示すためのただのネタで、これを本気で使ってる奴はいないだろう Option + P でπが入力できることは当然知ってるよな？ 聞いてもいないのにいきなり言い出して確かにイタいな 急にJavaを比較対象として出して草
ObjCと比較しろやw >>326
うぅー。知らんかった。というか、忘れてた。
昔ΩがOption-Zで入力できるのを使ったが、それっきり。 >>330
Javaとの比較歓迎なんだけど、俺は。
Javaで仕事した事ないけど、情報処理の試験対策で勉強したし。
Design Patternの本読むのに、Javaで理解したし。 iアプリやAndroidくらいしかやったことないと比較はJavaで適当だろうけど
動作OSとかランタイムの在り方とか言語文法の系譜とか違いすぎる
同じAppleOSで動いて、.soランタイムだけ要して、without C程度の系譜の同じ土俵で評価すべきじゃね
自分が知ってる言語って程度で比較に挙げるならC#でもGoでもRubyでもなんでもアリだからw 非ASCII識別子のネタなんて何の言語引き合いに出しても別に問題ないっしょ メモリー管理方式取り入れるってニュース見かけたんだけど
Swiftまた互換性無くなるんか？ 「タイム互換」短すぎやでほんま
タイム互換いいたいだけやけどな ＿ ＿＿
／ ＼ ／ ＼
／ ＼ ／ ＼
／ ／￣￣＼ ＼ ／ ／￣￣￣＼＿_＼
／／￣ /￣|￣ |￣`くヽ＿_/> | ＼
￣ `ー'`ー'｀ｰ'／⊿⊿ヽ ￣￣
| | / ､／⌒ヽ,ヽ ／￣￣￣￣￣￣￣￣￣￣￣
| | | | 〇 O） | ＜ ﾌﾞﾀﾓ ｵﾀﾞﾃﾘｬ ｷﾆﾉﾎﾞﾙ｡｡｡
| __|＿>￣￣￣く ＼＿＿＿＿＿＿＿＿＿＿＿
| (＿__ノ |
| __|_|＿ /ｅ
| （＿__ノ､＿__／
| |
| |
| |
| |
| |
| | またInfoQは2ヶ月前の話を今更ニュースにして
今日の本当の界隈ニュースはABI Dashboardがやっと公開されたこと >>344
翻訳がひどいなぁ。
ChridではなくChrisだし、マニフェストではなく、「今後の予定」だし。 結局、C++11 unique_ptrの文法ラップなのかな
ObjCでも使えるなら使いたいから頼むよー Rust inspiredとのことだからunique_ptrなんてレベルじゃない
ライフタイムかそれに類するものを導入する気だろう Swift4で何がかわりそうなのか
ttp://qiita.com/d_date/items/b3562f542afc306791ce SE-0110
Swift3.1
let fn1: (Int, Int) -> Void = { x in
// some procedure
}
Swift4
let fn1: ((Int, Int)) -> Void = { x in
// some procedure
}
Intを要素とするtupleを引数に取るclosureの記述方法が、変わるらしい。
(Int, Int)型引数は、((Int, Int))としてx.0, x.1って感じでアクセスする。ってこった。 func curry<A, B, C>(_ f: @escaping (A, B) -> C) -> (A) -> (B) -> C {
return { x in
{ y in f(x, y) }
}
}
この関数の読み方が判らん！
戻り値が
(A) -> (B) -> C
って事は、
1. A型の引数を受け取り、(B) -> Cなるclosureを返すclosureが戻り値
2. (A) -> (B)なるclosureを受け取りC型を返すclosureが戻り値
どっちだ？ >>352
AとBの二つの引数を持つclosureを
指定したAに値を固定した場合のBだけを引数にもつclosureを返す、というclosureに変換する関数 もういい加減にしてほしいな
言語ヲタが「ボクチンが考えた最高の言語」遊びしてるようにしか見えない ->が出てきたらその時点で->より前が引数、->より後ろが戻り値 >>357
なるホドォ
((A) -> B) -> C
これは、
引数 ((A) -> B)
戻り値 C
ですね。 >>358
RxSwiftのソースみてると、こんなんばっかり。
Reactive.itemsメソッドとか！ >>354
まあ、curry化ってそういうものだしね >>355
SE-0110でググって最初のリンク開けば Bug: SR-2008 が目に入って
バグ対応なんだな、くらいはすぐに察せる
目的や理由も捉えないと余計に遠回りになるだけだぞ >>350
いいからさっさと++、--、for(;;)を復活させろ >>352
くっっっそ読みにくいな
さすがswiftだわ >>355は4で破壊変更あることを今更知ったnewbieじゃないかな
破壊しないswiftなんてswiftじゃないと思って使ってるけど、3で安定したと思っちゃった子はそこそこいそう >>355
こんなぶれぶれの独善言語についてってる奴の気が知れんわ 型表記中の「->」は右結合ってことでいいんだよね? https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/Types.html#//apple_ref/swift/grammar/function-type
If a function type includes more than a single arrow (->), the function types are grouped from right to left.
For example, the function type (Int) -> (Int) -> Int is understood as (Int) -> ((Int) -> Int)
―that is, a function that takes an Int and returns another function that takes and returns an Int.
引数は必ず()で囲まないといけないから、もし ((Int) -> (Int)) -> Int なら前半の()が必須
そういう意味でも (Int) -> ((Int) -> Int) としか解釈できない >>370
THX
原則は、
1. 引数は()で囲む。囲まないと、error: require parentheses
2. 右から左方向へグループ化
例：
(S) -> (T) -> (U)
は
(S) -> ((T) -> (U))
と解釈される。 Reactive.itemsメソッドがこんな感じ
public func items<S: Sequence, Cell: UICollectionViewCell, O : ObservableType>
(cellIdentifier: String, cellType: Cell.Type = Cell.self)
-> (_ source: O)
-> (_ configureCell: @escaping (Int, S.Iterator.Element, Cell) -> Void)
-> Disposable where O.E == S {
以下略 右から左方向が優先度高いのか
左から右に流してるイメージで逆方向のがしっくりくるが
関数型の思想としてそういうものだっけかな >>366
初期から使ってるけどSwiftにはいい加減枯れてくれって思ってる。
社内で必死こいてSwift移行推進した人たちは今肩身の狭い思いをしてるのでは。 Ojb-C使ってても毎年のようにAPIレベルでDeprecatedが量産されるから
Obj-Cなら変更コストが低いってわけでもない >>351
3.1で4の書き方でやったらどうなるか試そうと思ったけど、眠くて忘れてたわ
誰かどうなるか教えて >>378
let fn1: ((Int, Int)) -> Void = { x in
print(x.0 + x.1)
}
fn1((1,2)) // => 3
//fn1(1,2) // error: extra argument、引数が多すぎ！ >>379
ということは、元々括弧を省略した書き方をしなければ問題ないわけね Swiftの関数の書き方に近いシンタックスの言語ってある？ たくさんあるかは分からんけど、Rustは比較的似てる気がする
Go とか Kotlin辺りもちょっと似てるかな String再実装の第一弾と複数行文字列リテラルがレビュー通った >>385
RubyのHere Documentみたいなもんか？
json = <<'EOS'
{
"language": "Ruby"
}
EOS let json = """
{
"lang": "Swift"
}
""""
json == "{¥n ¥"lang¥": ¥"Swift¥"¥n}"
閉じ"""の行と同じインデントが自動的に削除される(行頭が閉じ"""に揃う)
便利 Javaにはないけどな
Swiftのはインデントまで考慮されて洗練されてるし インデント考慮って逆に分かりづらくなるような気が。。。
Optionalもそうだと思うけどSwiftって一見便利そうに見えて却って面倒くさくなってる要素が多いと思う >>392
あんまり、ルールが多くなると、C++みたく、不人気になるんだよねぇ。 >>390
1.0 stableだ、ヒャッハーって始めて、その後半年単位で破壊変更受けた絶望に比べたら別に、、、
発展途上どんと来い、商業採用しない前提でポストObjCの進化は愉快 >>393
今のSwiftも十分ルール多いと思うぞ >>395
同意
だから、Swift不人気になって、だれも使われなくなる。
ってストーリー展開が危険。 >>394
破壊的変更だけど、事前通告もあるし。。。will be depreridated. warningとか。
納得できる変更だし、改善方向に向かってるのでOK。
改悪とか、こんな機能、だれも使わんぜぇ。ってのが無いのでoK.
Windows 10の3D Paint Brush機能って必要か？ Swiftって読みにくすぎ
ObjC 3.0でいいわまじで
政治的に生まれた言語はどこかで無理が生じる ObjCの方が読みづらいわ
読みづらいというより書きづらい…かな ObjC-2.1っての出してくれないかなぁ。
Swift2.x -> 3.xへの破壊的変更をObj-Cへも適用して欲しい。
たくさんあるinitializerをinit(xxx:)にまとめるとか、Foundation, AppKitにあるClassのメソッド名を洗練させるとか。
Foundation, AppKitって1980年代の設計のままだから、あの長いメソッド名を
ちょっとだけ短くするだけで、まだまだObj-Cは延命できそうな気がする。
Swift3.x見たく、メソッド名の短縮化をObj-Cへcome on! Obj-C開発コミュニティーは崩壊しており、いまさらObj-Cのupgradeは難しいって事でしょうか？
だから、Swiftの開発が始まったって事でしょうか？
Obj-Cってコンパイル早くていい感じ何ですけど。Xcodeもサクサク動くし。
SwiftのせいでMacbook Pro15買わなくなっちゃいましたヨォ。俺は！ >>403
Objective-Cの考え方は、ドキュメンテーションコード。
だから、名前を短くするのはナンセンス。 単純に文の長さが短いだけで読みにくいのは高級言語としては微妙だな 「!」は最初見たときは分かりづらいと思ったが、慣れると危険な部分が分かりやすくて良いなと思ってる プログラミング初心者なんですが、 delegateの概念がよく分かりません。
プロトコルは実装しないといけないメソッドとかをまとめるもの？という認識ですが。
開発チュートリアルやってると、なんの説明も無しにいきなりdelegateは何とかを他のクラスに委任できるなんちゃらとか、
説明が意味不明過ぎて詰みました
だれかわかりやすく説明できる方いますか？
わかりやすいサイトでもいいです
英語サイトやYouTubeでもいいです >>411
スレチ、とかってのは無視してOKっすからね。
あとdelegateパターン、delegateメソッド、delegate変数って言葉を使える様に
ならないとね。
delegateの概念ってのは、「クラスに委任」とかっていうのは単なる辞書を引いた
だけの説明なのでこれも無視です。
delegateパターンってのは２つのクラス、１つのプロトコルを使ったパターンです。
あまりにも、当たり前に使われるので、説明無しにdelegateパターンって出てきます。
この記事が参考になるんちゃいまっしゃろか？
UIKit類似Frameworkを自作してみる
http://qiita.com/externvoid@github/items/c70ce09aea758a548b22 デリゲートってのはなぁ・・おっと、後は>>145頼む >>413
スレチはスレチ
swiftに関係ないし初心者質問スレでもないので質問者の想定レベルが不明
しかも>>413はdelegateの説明をしていない
あと紹介するなら、こっちじゃないの？
http://qiita.com/mochizukikotaro/items/a5bc60d92aa2d6fe52ca
iOSに限定したdelegateへの質問なら、こっちの方が答えがあると思う
[SDK]iPhoneアプリ開発初心者質問箱48[touch][iPad]
http://egg.2ch.net/test/read.cgi/mac/1484217623/ 片側Rangeが通った
a[..<i] とか a[...i] とか a[i...] ってデフォで書ける 今までデフォじゃなければ書けたの？
ユーザが拡張可能なコンパイラプラグインIFってswiftにあったっけかな a.prefix(i) // a[..<i]
a.dropFirst(i) // a[i..]
と、手で書き換えるとか？ prefix operator ..<
prefix operator ...
postfix operator ...
を定義するだけ
SE-172のDetailed design真似して3.1で書いてみた
http://swift.sandbox.bluemix.net/#/repl/58febd1c8ef5d90dc580fb9b
まだSE-148のジェネリックなsubscriptがないから、ちょっとコードの重複ができてしまった >>421
動いた。
こんなのチャチャッっと書けるなんて、すごいねぇ。 あー、オペレーションのオーバーロードか
オーバーロードしてまで使いたいとは思わないけどpythonの同類文法が使えるようになるのは幸せ
>>419-420
とか定期(俺が日本語不自由 >>411
https://developer.apple.com/library/content/documentation/General/Conceptual/DevPedia-CocoaCore/Delegation.html
http://best-practice-software-engineering.ifs.tuwien.ac.at/patterns/delegation.html#Structure
https://code.tutsplus.com/articles/design-patterns-delegation--cms-23901
Delegateはデリゲーションパターンにおいて処理を委譲されるクラスの役割名
「委譲する」という意味の動詞としても使われる
プロトコルは他言語で言うインターフェース
DelegationはCocoaでフレームワークから開発者の書いたコードを呼び出す場合によく使われるパターン
例えばTableViewの行を選択した時に何か独自の動作を行いたいなら
UITableViewDelegateに定義されている特定のメソッドを実装してDelegateとして設定しておくと
ユーザーが行を選択した時にDelegateとして設定したクラスの該当メソッドが呼び出されて開発者が書いたコードが実行される
UITableViewDelegateがプロトコルでそのプロトコルを実装したクラスがDelegate
プロトコルとの関係がわかりにくければUITableViewDelegateProtocolという名前を省略してると考えてるといいかも でもAppleはblockを奨めているから
今時delegateじゃないよね
まあ知っておいた方が良いかな程度？ >>424
thx
２番目のURL記載のMultiple Inheritanceを避けて
Single Inheritance with Delegationってのが判りやすっすね。
CにはAの機能とBの機能が欲しい。じゃぁ、CはA, B２つのクラスを継承させれば良いか？というとそうでは無い。
CはAを継承しつつ、Bをメンバに持てば良い。 is-a関係、part-of関係がはっきり決まるオブジェクト間の関係ばかりでは無い。
例：
- 正常運転 is-a 運転、復旧運転 is-a 運転
- 正常運転 part-of 運転、復旧運転 part-of 運転
同じ概念間にis-a関係、part-of関係の両方が同時に成立する事は
ありえず、どこか間違っている。
is-a関係：Interitance
part-of関係：delegateパターン
両者を上手く使い分けるのが吉！ >>426
スレチだけどURLConnection(非推奨)とURLSession(推奨)見比べろ >>425
>>430
クラスやメソッドの役割によるもので単にBlock推奨、delegateが古いという話ではない
NSURLSessionのヘッダ見りゃ分かるけどSessionとTaskの関連メソッドではdelegateでの定義の方が多い 数で比較するんじゃなくて、どっちをユーザに使わせようとしてるかを比較するんだよ？
UIAlertController(推奨)とUIAlertView(非推奨)みたいなのもあるな すまん、数を持ち出したのは間違いだったが物事を単純に考えてる奴には目で見て分かりやすいと思ったので
新しいAPIでもcompletionHandlerもあればdelegateもあるし適材適所って事 適材適所であることに異論はないが、今までdelegateだったものがblockに移行してる事実はあるよね
>>426の「何の関係があるの？」の疑問は解決したかな
同じようにObjCだったものがSwiftに移行・・・はして失敗してるんだよなぁ
Swiftに移行したけど破壊変更が頻繁でメンテナンス性が悪いからObjCに差し戻そうって意見が割とガチで出て辛い >>430
なるほど>>425が言いたいことは理解したわ
Delegateをコールバックを実現する仕組みの一つとして捉えると
わざわざDelegateを定義しなくてもcompletionHandlerみたいなblockパラメータって十分ってことかな
シンプルなケースはそれでいいけど少し複雑になるとDelegate使ったほうが良いケースもあるし使い分けだよね
自分で新しく作るんじゃなくUITableViewDelegateみたいなフレームワークで用意されたプロトコルを使う場合は
コールバックを実現する仕組みというより事前に用意された拡張ポイントを使う方法として捉えてる
その場合サブクラス化、デリゲート、イベントなんかは同じグループとして捉えてるけどBlockは抽象度違うからグループの外だね SwiftのprotocolはJavaのinterfaceみたいなもんだと説明されるけど、Javaでoptionalメソッドを定義できるの？ そもそもfuncとmethodを分ける意味ってあんの？
会話で通じないとかなくね？ 関数の事をmethodって言う奴は「解ってないなあ」と思う。
あと、宣言と定義の使い分けできていない人も苦手だな。 ヘッダーがなくなった時点で、宣言も定義もほぼ同義じゃねーの Swiftでは公式に用語がどう定義されてんだろうと思って探したら丁度ズバリ書いてた
https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/Declarations.html#//apple_ref/doc/uid/TP40014097-CH34-ID351
In Swift, most declarations are also definitions in the sense that they
are implemented or initialized at the same time they are declared.
That said, because protocols don’t implement their members, most
protocol members are declarations only.
For convenience and because the distinction isn’t that important in
Swift, the term declaration covers both declarations and definitions.
Swiftではプロトコルとか一部除いてほぼ宣言と同時に定義するし、いちいち区別するのメンドクセーから「宣言」も「定義」もひっくるめて「宣言」って用語だけ使うわー
まぁそれもBNFだけでの話のようで、Guideの他の部分の文章では「definition」も使われたり混同されたりしてるようだけど >>443
うっそーん？
instance method, type methodっていう言い方はするが、
instance function, type function(class function)なんて聞いたこと
ないぞぉ。 >>443や>>447みたいなことを口に出す人は若いなぁと思う
自分も若かりし頃は気にしてたけど年取ったら思ってても意図が伝わればどうでもいいわとなった
どうせswiftコード上だとfuncが共通で使われるし、小面倒な奴と会話するときは「ファンク」とでも言っとけばおk いやだからなんでfuncって書くのにメソッドやねん
だったらmethにでもしとけばええやん グローバルな関数とメソッドでfuncとmethを書き分けろっての？
ただの関数にmethとか使うのは抵抗あるわ
メソッドにfunc使うのは他の言語の例もあるので違和感ないけど そもそもメソッドというのはSmalltalkのコミュニティが使い始めた用語で
もともともはメッセージを受け取ったオブジェクトが目指すゴールを記述するための新しい言語要素を想定してたんだよね
だけど、けっきょくそのSmalltalkも-76以降はSimula67（ALGOLの拡張）スタイルの普通の関数に落ち着いたし
その後ブームとなったJavaもそのまま用語を採用した経緯もあって
メソッドと関数っていうのはインスタンスとオブジェクトみたいなもので区別はあまり意味をもたなくなっちゃっている
強いて言えば、クラスに属する（言語によってはプラスして暗黙のselfを受け取れる）関数をメソッドと呼ぶとかゆるいくくり >>451
それも、うっそーん！
Smalltalkではmethodをmessageっていうゾォ。 >>453
ああ、それはSmalltalkの（というかOOPの）メッセージングというコンセプトをよくわかっていない人がやりがちな間違いで
メッセージと、それを送ることでコールされるメソッド（関数）は別物
たとえばメッセージ（仮にmとしよう）を送ってもmとは関係ないメソッドがコールされることもあるし
極端な話、何もしないという選択肢（振る舞い）もありうる
もっとも多くの場合、メッセージ（厳密にはメッセージを構成するセレクタ）とメソッド名は一致させるのが普通なので
混同するのも無理からぬことだけれども Obj-Cの場合はメッセージ=メソッド的なとこあるけど、Smalltalkは違うんかね >>455
んー、Obj-Cのコミュニティ（Appleの公式文書も含め）が勘違いを広めているってよくない傾向はあるけど
Obj-CもSmalltalkもメッセージングの根本の考え方は変わらない
そもそもObj-CはSmalltalkのやっていることをCのプリプロセッサでやろうとした試みからスタートしたので変えたら意味ないし
ちなみにそのときの文法はまだメッセージ式ではなかったから純粋にコンセプトだけをなぞろうとしたことがわかる
http://dl.acm.org/citation.cfm?id=948095 (残念ながら有償）
mySodaMachine = {| SodaMachine, "comb:model:", 23, 4 |}; 以上って言っても、small talkやobjcについてスレチ上等で会話してる奴等には通じない、、、
大元の>>440だけ考えたら、コード上でfunc, methの書き分けなんて面倒っていう
コンパイラ側とコーダー側の双方メリットによるものだろうよ 戻り値が void の function なんてのは C で初めて見た。
例えば BASIC や Pascal では戻り値が無いのは procedure で 戻り値があるのが function だ。
method はやり方とか手順とかいう意味で routine や procedure と同じような意味合いだ。
function というからには副作用が無い（引数以外が戻り値に影響しない）ことを期待したいところだが、「機能」という意味合いに着目すると、これらの中で最も曖昧であって、一つで済ませるなら便利かもね。 >>458
つまり全部関数って呼べばいいんじゃないの
わざわざメソッドとか言わずに >>464
普通の人はそれで良いと思う
頭固い偏屈な奴だけメソッドって言い張れば良いんじゃないかなぁ
と自分は思います 教祖様がコード上はfuncをキーワードにするけど、>>457の通り人間向けはmethodがいいって言ってる
ケースバイケースで言い換えたい所存、信仰したくない宗教だけど敬意は払う
信者はsmall talk原理主義やobjc至上主義で討論してるけど結論出ないだろ >>464
メソッドって呼んだ場合は単なる関数じゃなく
クラスや構造体なんかの特定の型に紐付いた関数だっていう意味が付随するの
それが不要だと思うなら全部関数って呼べばいいと思うよ
メソッドに限らずクロージャなんて呼ばずに全部関数って呼んでもいいし
逆に関数なんて呼ばずに全部クロージャって呼んでもいい >>458
クラスや構造体の中で定義した関数のことをメソッドと呼ぶんだからfuncキーワードを使うのが適切だろ
コンパイラ側とかコーダー側とか関係ない >>467
じゃあなんでfuncとかいうキーワードなのって思うよね
つーか、キーワードなんかいらなくね？って思うんだが
そのキーワードがないとコンパイラが解釈できないシンタックスなのかな キーワードないと宣言なのか呼び出しなのかコンパイラも判断に迷うだろ >>469
もしmethodってキーワード使うとしたら、>>457の定義に従えば
メソッド = 型に関連付けられた関数
func = 関数
class { func } = 型に関連付けられた関数
= メソッド
class { method } = 型に関連付けられたメソッド
= 型に関連付けられた(型に関連付けられた関数)
ってことになって「頭痛が痛い」みたいにならね？w arc4random()をIntに入れるのに完璧なやり方ってある？ >>470
Cはそんなfuncとかいうキーワードないのに成り立ってて不思議だね C言語の場合
プロトタイプ宣言
と言うように、宣言はメモリの確保を伴わない
関数定義
と言うように、定義はメモリの確保を伴う
オブジェクト指向の場合はどうなるんだろうね
コードは宣言でインスタンス化は定義かな JavaとかObjective-Cでもfuncとかいうキーワードはないのに成り立ってるね 他の新興言語のgoやrustはキーワードつけてるね
あってもなくても成り立たなくはないけど、ある方が流行りなんでしょ
他言語文法仕様をパクってモダンなものを作るんだから流行りに合わせてつけるのは当然でしょ >>478
それな
モダンな表現を実現するためには仕方ないな 明示しないとコンパイラだけじゃなく人間も頑張らなくちゃならなくなるかも >>473
Cは変数も関数も型宣言（関数の場合は返り値の型）が先にくるからね 構文解析の問題だからメモリ確保云々は関係ないでしょ
funcキーワードを使わないとして
例えば foo() {…} と書いた場合にこれが関数定義なのか
Trailing Closureを付けて関数を実行しようとしてるのか{…}の中身を調べないと分からないし
未定義のものを実行しようとしてるのかどうかの判定も困難
キーワードがあることで構文解析・静的解析・型推論なんかで有利に働いて
言語としての表現力や安全性が高まる 特に表現力
funcじゃなくてletやvarを使ってもいい(Swift的にはこれらは関数とは呼ばないけど)
let foo = {print(“foo”)}
let bar = {() -> () in print(“bar”)}
let baz: () -> () = {…} >>472
Intに入れるじゃ何聞きたいのか分からん
var result: Int = 0
arc4random_buf(&result, MemoryLayout.size(ofValue: result))
こういう話？
それとももっと別の話なのか >>472
普通にIntでCastして不都合ある？
let random10 = { Int(arc4random_uniform(10)) } 『詳解Swift』ってどう？Amazonの評価は真っ二つに別れているんだけど >>486
どんな本も、読者によって評価は分かれる。
いい本とは、万人に受け入れられると考えるのは、間違い。 中上級者向けの本で内容を理解出来ないと悪いレビューつける奴いるしな swift 3に対応した3版は出たのかねぇ
作者も読者も疲れてそうだと思った >>486
Appleの公式本読めば十分だよ
日本語という以外の付加価値は全くないけど
公式本に近い内容を日本語で読みたければ買ってもいいと思う
一度読んだら辞書的な使い方はしないので電子版のほうがオススメ
あと荻原本は公式本よりやや説明がくどいので好き嫌い分かれる
目新しい概念をわかりやすく説明してくれてたりはしない >>488
百田尚樹の本をサヨクが理解出来ないのと一緒だな どうせSwiftの自己満仕様変更で古くなる参考書を何故買うかね？ 古くなるのが嫌なら、IT系の本、特に入門書なんて全部買えないだろ。
それに図書館で買ってもらって読むって手もあるし。 >>489
疲れたヤツも居れば、元気なヤツも居る。
C++11, C++14, C++17と立て続けに改定が進み、
疲れたヤツ、元気なヤツが居るのと同じ。 >>492
全ての仕様は、古くなる。
全ての物理常識は古くなる。
天動説だって古くなる。
だから、天動説を知らないで良いとはならんだろう。 コンピュータの世界はどんどん新しくなるのが当たり前だろ。
言語は、その中でもまだ遅い方よ。 ネットの情報は新旧混在ですぐデブリだらけになるからな どんどん新しくなるといいながら、未だにフォン・ノイマン型が主流なんだよな ハーバード型もパラダイム的には大して変わんねーから データと命令で分かれてるのは地味に重要だぞ。
高速なCPUじゃ分かりにくいかもだが、低速になる程顕著。 >>496
言いたいことはまだ発展途上の言語はweb上のドキュメント参照しとけばいいってことだよ >>498
最近debrisってよく見かける単語だなぁ。
Apple系News Sitesでよく見かけるなぁ。 フォン・ノイマン型 ハーバード型
ってなんの話だ？ AVR, PIC vs Intel, ARM
って事なのね。 早々にSwiftに移行した人達よ、工数人件費は抑えられた？上がった？ >>491
キチガイの発想は健常者には理解不能だよなあ >>507
swift1.1で業務採用して2.3までメンテしてたけど、ムリゲーだwwwってレポート挙げてobjcに差し戻した
工数人件費はお察し >>509
ちょっと、どう言う状況なのか？理解不能。
Swift2.3 - 3.xへの移行が難しいってのはどう言う事？
Unsafe族を使いまくってたのとか？
それでも、なんとか移植できるでしょ。2.x -> 3.xはそんなに
困難？
これから段々、Obj-C世代が居なくなるよ。 1.xの頃は開発環境が業務に耐える品質じゃなかったし
2.xはまだマシだけどやっぱり更新頻繁だったんよ
半年単位で言語仕様、API仕様が変わってたからメンテ工数がobjcの比じゃなかった
2.3から3の移行が厳しいんじゃなくて、それまでが悲惨すぎてもうやめよってなった
比較的更新速度の遅い3.0以降で業務採用始めてたら違ったかもな
まぁ早々に移行したヤツと、最近移行を考えてるヤツは状況違うから、あんまり参考にならんよ うちはまだSwift2.3 - 3.xへの移行まだしてないな。
GCDあたりとか手作業で書き換えないといけないらしいし、
いっそObj-Cに戻したほうがSwift3→4移行の時も苦労しなくて済みそうな気がしてくる。 swift5もでるみたいだから毎年苦労することになる。 4からCIでソース互換性テストやるようになったから大丈夫だろ >>518
Appleが政治的にゴリ押してるから移行する必要性が出てるわけであって、技術的にはそれもあり >>518
数年しか使わないアプリならそれでいいんじゃない。 >>517
俺は十分に安定したと判断したからswiftに移行したけど、予想が外れたら恨んでくれて良いよ swift触るよりreact native とtypescriptでいいんじゃないかな？
reduxでステート管理できるぜ >>522
react nativeもなんだかなぁ。
結局JavaScriptだけで、アプリ作れる訳では無いし。
RxSwift触ってるけど、
なんで、Variableとか、Driverとかがあるのか？良く判らん。
おまけに、RxSwift3.4になって、他にも色々増えてるし。 Variable, Driver
Single, Maybe, Completable
ってのがあるんだけど、こんなにViewModelが必要なのだろうか？ >>521
ABIの安定化がようやく4でなされる予定で、文法の下位互換保証は5とかになるんじゃないのかね
そんな状況下で仕様安定というのはまだ時期尚早だと思うぞ ずっと前から定期的にswiftが安定したかどうかをこのスレで尋ねてきたんだけど
今回初めてポジティブな反応があったってのは喜ばしいです
これから勉強するって立場だと、前みたいにあまりにも大きい変更があるなら
手を出しづらいけど、
そこまで大きくない変更があるぐらいならなんとかなりそうだし、
仕様が安定した頃にはバリバリ書けてる様になれるのが理想なので
そろそろ勉強し始めてみるよ
またこのスレにはお世話になると思うので
今後もよろしくお願いします ABI安定化は延期されたから4には入らないって何度言わせるんだ あん？3が見送りで4で安定(予定)じゃないのかいな
swift-evolutionのREADMEでは4に入ってんぞ、これからまた変わったのか？ >>523
でも大概のアプリの要求は満たせると思うが。何よりマルチプラットホームなのが嬉しい。
とはいえ、typescrptにも限界はあって
やはり動的言語を無理やり静的言語に見せかけているゆえの謎の不具合は避けられないんだよなぁ >>529
Swiftが進歩してもらうのはウェルカムだけどObjective-Cよりメンテコストがかかるのなら敢えて採用は出来ないって会社判断もある
うちはもっと安定してからかな import Foundation
extension NSObjectProtocol {
static var className: String {
return String(describing: self)
}
}
print(String.className) // =>NSString
print(String(describing: String.self)) // =>String
最初のprint文の出力は、これで良いのでしょうか？
Terminal.appで実行しました。
513> swift -v
Apple Swift version 3.1 (swiftlang-802.0.53 clang-802.0.42)
Target: x86_64-apple-macosx10.9
です。 あと昔、NSObject classとNSObject protocolの２つがあった様に
記憶してますが、
protocolの方はNSObjectProtocol protocolに改名されたのでしょうか？ obj-cのNSObject protocolがswiftのNSObjectProtocolなんですね。 ストーリーボードを使わずに開発したいんだけど、参考になる書籍がなかなか見つからん..
なんかオススメの本あったら教えてくれ >>536
ストーリーボード使えばいいじゃん
楽だよ 便乗で質問です。
Swiftの言語自体の解説は書籍もサイトも見つかるのですが、
ストーリーボード自体の解説をしている書籍とかサイトって、
あまり見当たりません。
なんかお勧めとかありますでしょうか？ >>533
バグっぽい
SE-0072 で String から NSString への暗黙的なキャストは禁止になったけど
NSObjectProtocol のメソッドを呼ぶときは暗黙的に NSString にキャストされるままになってしまってる
今 master の最近のビルドで試してみたらコンパイルエラーになったから 4.0 で修正されると思われる
print(NSString.className) // NSString
// print(String.className) // error: static member 'className' cannot be used on instance of type 'NSString'
print(type(of: "" as NSString).className) // NSString
Swift version 4.0-dev (LLVM 3df4892fbe, Clang 1a30829a18, Swift 79258866a2)
Target: x86_64-unknown-linux-gnu >>538
使わないほうがプロジェクトの管理的にいいんですよね..
>>541
すみません、誘導ありがとうございます。
そちらのスレで質問してみます。 >>544
>使わないほうがプロジェクトの管理的にいいんですよね..
なんで？ 意味が分からん 1つの.storyboardを複数名が修正して発狂するのはiOS/macOS開発の宿命
じゃあswiftだけ作ればいいって言うと更に発狂するし
storyboardを複数に分けるとビルド時間延びて発狂する
ホントXcodeはクソやでぇ、、、
まぁビルド時間はswift使う時点で頭くるほど延びてるんだけども
1.xの頃はホントシネと思った 1つでかいStoryboardがある場合とそれを分割した場合とじゃ後者の方がビルド早くない？ビルドキャッシュのおかげかな？ >>540
THX
WWDC2017ではSwift4.0betaが出現かなぁ。
Swift3.1と4.0betaは共存できるのかな？ Swiftで開発中にハマまくったけど結局コンパイラのバグだったって経験ある人いる？
そういうのが怖くてSwift始められない人って多いと思う。 >>549
540にbugの例があるだろ！
bugの回避を見つけられないなら、始めない方が良いと思う。 ［速報］マイクロソフト、「Xamarin Live Player」発表。Visual Studioで開発したコードを直接iOS
/Androidデバイスに転送、実行、リモートデバッグ。Mac不要。Build 2017
http://www.publickey1.jp/blog/17/xamarin_live_playervisual_studioiosandroidmacbuild_2017.html
Xamarinに移行するわ。 >>551
なかなか、良さそう。
Xamarin Live PlayerってのiPhoneへ放り込むって事で、WiFi経由でdebugできるってことか。
1本1,000円のLightning Cableが不要になるのはありがたい。 グダグダなswiftをみると、まともなC#に移行したくなるわな Microsoft Fluent Design System - YouTube
この動画感動。なんかすごそう。
簡単に、こんな、UI/UXできれば良いが。 あの日の夕暮れ時の輝くUnityみたいな君の笑顔を忘れない
Forever >>551
ますます、Swiftの存在価値に疑問符が打たれてきたな >>561
Appleと協議してOK出てるらしいよ Xamarin Live Playerを使うことで、MacがなくともiOSデバイスへ開発中のアプリケーションをデプロイできるようになったため、
アプリケーション開発段階ではすべての作業をWindowsマシンだけで行うことができるようになりました（ただしAppleへの申請などのためにMacは必要となります）。
＞ただしAppleへの申請などのためにMacは必要となります
＞ただしAppleへの申請などのためにMacは必要となります
＞ただしAppleへの申請などのためにMacは必要となります
Appleも抜かりはないな >>563
でも、それだけであればくそ高いmac本体買わないで済むわ ユーザ拡大になるし、Mac miniでも買ってもらえるし、Developperプログラムの年会費も払ってもらえるし
まぁ、Appleにとってもメリットあるしな 今までありがとう！Swift
Thank you Swift !!! 低消費電力でモデム内蔵のARMベースプロセッサを使ったWindows 10マシン
今年年末に登場しそう。 言語(swift)と開発環境(Xamarin)を比較しても意味もなし
でも久し振りのXamarinステマ荒しは懐かしくて感慨深い
MS買収前に結構必死にステマしに来てたよな
挙げ句、荒し隔離のためXamarin本スレが立てられたのは何年前か >>570
Xcodeの補完機能があってこそかろうじて使えるswiftをわざわざ他の環境で使うメリットがあると思うなら書いて欲しい IntelliJ系列のどこぞのIDEがswiftもサポートしてたはずで
Android Studioと操作が変わらないから Android/iOS平行実装の開発効率が良い、と夢物語を言ってみる
実際はstoryboardを十分に扱えない時点で耐えないんだけども
UI伴わないライブラリ部分の実装なら可能性はある？ ちょっとしたことでXcode立ち上げるのめんどいときはAtomやVimもよく使う >>575
俺もコードの断片を試すのにVim使ってる。
Atomも気になるけど、まだ未体験。
command+Iでコードを実行できるってのが素敵。 vim + swiftc は正義
メモリ4Gの安いものMBAだとXcodeも重くてたまらんわー >>578
偉い！
4GでXcodeは、Yosemiteだと割と快適だった。
SierraになってmacOS自体のメモリ消費が激しいのかな？
Xcode重いぜよ 【北朝鮮ミサイル】射程４０００キロ超か
株売って、疎開せえやwww >>577
Xcodeたち上げっぱなし、俺もそう。 開発機の予備が欲しいんだけど、どっちが良いだろう？
MacBook Air 1600/13.3 MMGF2J/A
最安価格(税込)：¥86,726
MacBook Pro Retinaディスプレイ 2700/13.3 MF839J/A
最安価格(税込)：¥118,330
どちらも外部LCD接続で使用予定。 iMac Retina 4Kディスプレイモデル MK452J/A [3100]
Retina 4Kディスプレイ搭載のiMac
最安価格(税込)：¥138,799 (前週比：-26円↓)
開発機にはこれが良いかも。Quad Coreだし、16GBメモリへ増設可能だし。 開発機の予備なら何でもいいんじゃない。
Appleはそれほど種類があるわけでもないし。 ちょいと長いコード(170lines)なんですが、コンパイル出来ずに困ってます。
http://swift.sandbox.bluemix.net/#/repl/591a4c9525273037d6da9847
ERROR at line 64, col 9: value of type 'Bag<AnyObserver<String>>' has no member 'on'
bag.on(.next(value))
RxSwiftと同じ動きをするclass, protocolを自作しようとしているコードなんですが、コンパイル成功させるにはどの様に修正すれば良いでしょう？
コードのオリジナルは、
http://qiita.com/gomi_ningen/items/dc08a8a5514be9aa0eb2
から拾って来ました。オリジナルをSwift3.1へ移植したコードをswift.sandbox.bluemixへ貼りました。 >>588
THX
今日は、現実逃避の為にRxSwift三昧です。
こんなメール
>>今期のxxxさんの業務目標について、iOSアプリについては、私から指示があります。
しばらく、ブッチしよう。 RxSwiftみたいな何年も前の流行りモノを業務時間内に学習してる後輩/部下がいたら指導するわw
Swift 2.xの頃にEitherフレームワークが便利！と食いついて3.0でorzになった奴らと大して変わらんと思うんよ
Either、使いやすそうだったから言語公式に入ってくれたら良かったのになぁ
3.0でthrowsが入った時には、ObjCとの兼ね合い上、そうなるしかないのか・・・とSwiftに対して諦観した >>582
air はクソ コンパイルが遅い
Swiftで使うのは酷だな >>572
結局そこだよな
ウンコ環境のXCodeでテキスト書かないと行けないのが
Swiftの生産性の低さだし C#とかJavaってテキストエディタだけでも生産性高いの？ C#はC#6以降は割とマジで生産性高い。
kindle本からのコピペでスペースがおかしいが。。。
u s i n g S y s t e m ;
u s i n g s t a t i c S y s t e m . C o n s o l e ;
c l a s s P r o g r a m {
s t a t i c v o i d M a i n ( s t r i n g [ ] a r g s ) {
W r i t e L i n e ( " H e l l o W o r l d ! " ) ;
}
}
using staticでSystem.Consoleまで指定すればWriteLineだけで良くなった。
その他色々短縮したり仕様上、出来なかったことが出来るようになったり。 >>592
orz、Swiftに諦観したのはそんな前だったか
それでもまぁあの頃は更新頻繁で楽しかった、今は更新少なくて寂しい >>596
これだけじゃぁ何がすごいのかわからないなりよ 以前は
using System;
class Program {
static void Main(string[] args) {
Console.WriteLine("HelloWorld!");
}
}
だったものが
using System;
using static System.Console;
class Program {
static void Main(string[] args) {
WriteLine("HelloWorld!");
}
}
で済むようになった、すごい！
なお、Swiftでは以下の一行で済む、Swiftもっとすごい！
print("HelloWorld!") :::::::: ┌─────────────── ┐
:::::::: ｜ C#がやられたようだな…. │
::::: ┌───└───────────ｖ───┬┘
::::: ｜フフフ…奴は四天王の中でも最弱 …. │
┌──└────────ｖ──┬───────┘
｜ Swiftごときに笑われるとは │
｜ 我ら四天王の面汚しよ… │
└────ｖ─────────┘
|ﾐ, ／ ｀ヽ /! ,.──､
|彡/二Oニニ|ノ /三三三!, |!
`,' ＼､､＿,|/-ｬ ト `=j r=ﾚ /ミ !彡
T 爪| / /￣|/´＿_,ｬ |`三三‐/ |`=､|,='|
/人 ヽ ミ='／|`:::::::/ｲ＿_ ト｀ー く＿＿,-, ､ _!_ /
/ `ー─'" |_,.イ､ | |/､ Y /| | | j / ﾐ`┴'彡＼
C++ Java JavaScript /ミ !彡 ●
|`=､|,='| ＿(＿
､ _!_ / ( ﾟωﾟ )
/ ﾐ`┴'彡＼ ' `
Visual Basic あれ。。。
SwiftってもしかしてLL？
インタプリタ？ >>599
皮肉が効いてるな
表面的なコード量が短いことが他の全てのことに優先して正義だと本気で思ってる奴がいるからな 表面的なコード量が長いことをコンプレックスに持ってる言語もいるよね・・・
そして、一長一短の他者を認めることもなく他言語を総じて悪と本気で思ってたり
>>603
ざっと見たけどSwiftで同等のこと出来てね？所詮、四天王最弱か >>591
あんた、厳しいなぁ。
それから、流行り物っていう評価はどうかな？
今後、廃れていくと言うことを、暗に言ってるつもりなのか？ Playgroundでシコシコ遊んでると、そのうち出力が表示されなくなったり無反応になるんだが
どうにかならんもんかね >>605
まあ最新はC#7で、おいらはプログラミングから離れたんでうらしま太郎状態なんだけどね。
VSやコンパイラもC#で作られたのがC#6からだっけ。。。 >>610
Visual StudioがC#で？
あの遅い言語のC#で？
それは本当か？ >>609
>Kotlin
こいつが気にくわないのが、val, varなんだよねぇ。定数、変数の違いを記述する方法が。
let, varにしてもらわんと、目がチカチカするわぁ。 swift -> kotlinコンバーターとか作れるのかなぁ？ SwiftはLLVMでコンパイルするんだからJVM向けバイナリ吐けばいいだけでしょ
なんでKotlinを挟む必要があるのか、それがワカラナイ(色んな意味でｽｯﾄﾎﾞｹ swiftでiOS勉強したいのですが、参考になるOSSのアプリとか無いでしょうか
ドキュメントから入るより出来の良いコードを見たい派です Kotlinのval,varはScala先輩に倣ったものだから仕方ない swift はそろそろ安定期に入ってもいいと思うんだ >>622
bugレポ、沢山上がってるが、これはどうする？ バグレポを出す時にプルリクをセットにすれば安定はすぐだ >>622
bugレポ、新機能追加requestともに増えている状況だから
安定なんて、無理じゃね？ Swift4 betaをinstallした後、Xcode8.3.2で切り替えながら使うqiita記事を見失った。
なんと言うタイトルだったか？どんなtagでqiitaを検索すればhitするのか？
教えてクレェ？ Xcode用のsnapshotはインストーラ形式だしダウンロードしてインストールしてXcodeのtoolchainで切り替えるだけの簡単操作やろ
Xcodeでの切り替えはXcode>Toolchainsか環境設定>Components>Toolchains
Terminalでの切り替えは
毎回頭にxcrun -toolchain swiftとつけて
xcrun -toolchain swift swift -version
とするか
export TOOLCHAINS=swift
すればいい
インストールされる実体は
/Library/Developer/Toolchains/xxx.xctoolchain
にある
.xctoolchain内のInfo.plistにあるCFBundleIdentifierをtoolchainの引数に指定すれば、複数のSnapshotをインストールしてても細かく切り替えられる
xcrun --toolchain org.swift.3020170515a swift -version
とか
去年はPlaygroundsがToolchainに対応してなかったけど今年は対応済みのようなのでPlaygroundsで色々試せていい
https://github.com/ole/whats-new-in-swift-4 Swift歴２年、アプリリリース経験無しの非IT系リーマンです。Generics protocolとか難しいなぁと思いながら、RxSwiftのコードを解読してます。
Fortran, C++のコードを書いて金をもらった事があります。C#, Java, Obj-Cもチョコっといじった事があります。
Swift, C#, Java, C++の４つの内、どれが一番難しいと思います？ 圧倒的にC++。
今でもMFCには玄人っぽさへの憧れはあるけど、MFCの本は最盛期に比べて大分減ったなぁ。。。
JavaやC#してから(特にC#のがC++に近いけど分からなくなる一歩手前まで取り入れてるからオススメ)、C++行くと理解が進むね。 AppleのReferenceで混乱してる記述を発見
1. メタ・タイプを戻すグローバル関数type(of:)の説明には、戻り値がMetatypeとある。
2. メタ・タイプを引数にとるUITableViewCell.registerの説明には、引数がAnyClassとある。
どっちかに記述を統一してほしい。 Metatypeはstructやenumも含めた型でAnyClassはclassだけじゃない >>633
Visual Studio6の頃までしか、MFCは知らんけど、
Microsoftは、MFCを放置してるんちゃうの？
同時に、C++11, C++14って進化してるのに、Micorsoft C++はこれも独自仕様
で放置されてる、ちゅうのが俺の印象なんすけど、違うんでしょうか？
最近のMicrosoft系開発環境に疎いので間違ってたら申し訳ないすけど。 >>634
違いは>>635（AnyClassはclassだけ）であってるけど
補足するとMetatypeという識別子の型は無い
あれは単なるジェネリクスのプレースホルダ名
実際のメタタイプの型は「(型名).Type」でAny.Type型にも入れられる
AnyClassは「AnyObject.Type」のエイリアスでclassのメタタイプのみ入る
ちなみにメタタイプの値自体はclass型でないのでメタタイプのメタタイプはAnyClassに入らない
class A{}
let a:AnyClass = A.self //OK
let b:AnyClass = A.Type.self //NG
let c:Any.Type = A.Type.self //OK /var/folders/4x/4kvmnvfd46zdv9xt45wf2kx00000gn/T/
vzb3TAU/1:20:19: warning: operator should no longer be declared with body
infix operator ^^ { }
~^~~
SwiftコンパイラーをTerminal.appで動かすと上記の様なwarningが出ます。
エラーの内容は^^演算子が定義されていません。って事だんですけど。これは、置いておいて、
1:20:19は何を表わしてるのでしょうか？20行目19カラムって事は判ったのですが、1は何でしょう？
１番目のソースって事なんでしょうか？ >>637
リボンUIはMFCらしいってのまでは追ってたんで、今も地味に進化してると思うけど、おいらも分からん。
あの機能は何の為かとか分かるようになったけど、結局C++触らなくなった。
再入門しようにも入門書の少なさよ。。。 ビルドキャッシュとして
/var/folders/4x/4kvmnvfd46zdv9xt45wf2kx00000gn/T/vzb3TAU/1
ってファイルがあるんじゃないの
一時的に作られてすぐ削除されるかもしれんから存在確認できるか知らんけど そもそもwindowsのアプリ開発でMFC使う事情って保守以外に何あるの？ このスレチの話題の結末が
MFCがmacOSで使える、そうSwiftならね
だったら感動する >>642
怖いもの見たさで再挑戦したいだけ。
スレチだし気にしないで。 >>642
動作の軽いアプリが作れる。
.netアプリは動作がモッサリ MFCはクラスライブラリとは言ってるけどただのモジュールだからなω KFCはファーストフードとは言ってるけどただのフライドチキンだからなω macもファストフードって言ってるけどハンバーガーなんだよな... バカッターの次はマスト鈍かよ
Swiftはコンパイル必要とかスクリプト言語だとかクッソデタラメばかり撒き散らしてやがる
Swiftはスクリプト言語のようにJIT実行もできるし事前コンパイルして動作することもできるっちゅーねん
よくわかってないからと言って既存のカテゴリに当てはめようとするからおかしくなるんだ。黙ってればいいのに。
twitterもマストドンもバカに絡まれたくないから間違ってても誰も訂正してくれないてことはもうそろそろ理解しないといけないだろうに kotlinのvar, valが嫌いだ。
var, letにしてくれ！ >>647
そうそう。
macで使えるようになって嬉しいとしたらDelphiのVCL。
C#の中の人(Delphiの生みの親)をMSから引き抜けw >>658
VCLって使った事ない。
けど、噂には聞いている。
最近のDelphiではiOSアプリ作れるのか？ RAD StudioってのでiOSアプリ作れるみたい。 >>659
.netがVCLに似てる。
ネイティヴ版.netって感じだよ。
言語がC++かObjectPascalってだけで。
.netのForms使えるならVCLも違和感無く使える。 >>664
なるほど！VCL良いじゃん。
Common Language RuntimeとかいうInterpreter無しに.netモドキが動くなんて。 >>666
ブラクラとは、どういう意味ですか。とは、どういう意味ですか？ 下のドキュメントを読むに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 どこに
>Copy On Writeで最適化する場合にはprotocolやclassでラップせよ
とか書いてあんだよ
>Copy On Writeって関数引数に単純なstruct型を渡した時の値渡しには適用されないって認識であってる？
んなわけねーだろ あ、すまん、Advice:の節を注視して前の節を飛ばしてた
> When we copy values (the effect of assignment, initialization, and argument passing) the program will create a new copy of the value.
値渡しはコピーするってしっかり書いてあったわ structは常にコピー
このstructはcopy on writeです、という場合も便宜上そう言ってるだけで、実際は中の参照型のストレージをcopy on writeしてるんであってstruct自体は常にコピー
ただしin-out引数だけは例外的にstructでも参照渡しになる場合がある copy on writeだから、コビーの必要性が生じた時にコピーが発生するんだろ
structであっても参照するだけならコピーはしない（はず） >>674
だよなー、昔もSwiftはCOWで処理するからコピーするわけない!!みたいな奴がいて
ずっと首を捻ってたから、このドキュメントで裏付け取れて良かったわ
>>672, 675
お前はフィーリングだけで物を言わず、COWの実装を学べ
あと>>671でprotocolでラップとか言ったけど意味ないな
protocolはI/F切るだけのものだから、class/structで差をつけないと参照/値渡しには影響ないわ structの参照渡しのためのin-out parameter(inout)は使いたくないと思った
それするなら、最初からclassでAPIを設計しろというね >>676
常にコピーなら、コピーオンライトとは呼べないな >>677
inoutを指定しなくないから、クラスにするって考え方がそもそもおかしい >>678
メモリ操作としてのコピーと、変数への代入時の複製を混同すると、そういう訳のわからない議論になるね
structはコピーオンライトと言っても、osやハードウェアのレイヤーになるとclassであっても必要に応じてコピー(と消去を組み合わせた移動)を行ってるんだけどね。
swiftのレイヤーでは、常にコピーされるって言って良いんじゃないかな
コピーの為に支払うコストがいつ払うことになるか、そもそも払う必要が生じるのか、っていう部分にコピーオンライトの概念が関係してくるだけなんだから >>680
ごちゃごちゃした理論は言語設計者の領域の話で
プラグラマ視点でのコピーオンライトという文脈では書き換え時にコピー（コスト）が発生するという単純な理解で特に問題ないだろ
じゃないと、Structは常にコピーが発生するからデータの粒度をなるべく小さくして関数への引数渡しも注意しないととか余計な設計負荷を意識しないといけなくなる structは値渡し、classは参照渡し、Array Structの中身はCOWで処理、プログラマはこれを意識して最適化しろ
と>>671のリンク先で言ってるわけだが？
プログラマのレイヤーで考えるべきことが提示されてるのに、なぜそれを見ようとしないのか でかいデータをstructにつっこんで扱う時に注意すべきことが書いてあるだけだろ
つまり代入が頻繁に発生する状況でも、そのプロパティに実際にアクセスがあるまでコピーを遅延させるテクニックについて触れられてるだけ
別に関数の引数に値型を使うなとかとんちんかんなことは書いてないな SwiftでCOW意識する人なんているんだ。
そういう人はC++とかRustとか使えばいいのに。 最適化しない場所も含めて意識くらいはするでしょ
その程度のことで言語を変える理由にはならんよ
むしろStructでCoWという設計だからこと気兼ねなく渡せるってことに気付いた方がいい 誤: StructでCoWという設計だからこと気兼ねなく渡せる
正: Array StructでCoWという設計だからこと気兼ねなく渡せる
どうしてもSturct全般でCOWが適用されると思い込みたいアホが食いしばってて笑う >>686
「Structが」じゃなくて「Structで」な
Arrayに限らず、StringやDictionaryなどのstructでCoWを実装したもの全般
classでCoWを実装する場合は使う側が明示的にcopy()clone()などを呼ぶかinitを使う必要があるが
structでは代入,引数渡し,戻り値がコピーセマンティクスなので透過的に扱うことが出来る COWの話題から、いつの間にか参照渡し/値渡しの解説になっててワロタ
結局はSturctでCOWが常時適用されるわけじゃないから気をつけようってこったな
参照渡し/値渡しの違いを知らないLL言語勢もいるかもしれんが、別の問題だから気にしない
>>671のReducing Dynamic Dispatchの節も面白い
SwiftはObjective-Cと違ってダイナミックディスパッチを減らす機構を持ってるぜ、と
これを徹底的に使い倒したら、局所的にはObjCよりSwiftの方が性能よくなる可能性が微レ存？ 細かいところだけどclassは参照の値渡しでinoutは参照渡し >>676
protocolにまつわる言い回しを色々見ますが、どれが適当なのでしょう？
1. protocolを切る
2. protocolを当てる
3. protocolに準拠させる
すべてadding protocol confromanceの訳語だとおもうんですけど。 最近のCPUはSIMD命令(SSEとかAVRとか言われるやつ）を内蔵していて、
でかいStructも一発でコピーできるって、理解は正しいっすかねぇ？
512bitレジスタが32個あって、しかもその32レジスタはペアで使える。
って事は、512bit x 32個 = 2Kbyteを一発でレジスタ -> メモリへmoveしたり
メモリ -> レジスタloadできる。
この理解はOKっすかねぇ。 >>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"しか表示されない >>692
え…
参照渡しと値渡しで違う動作するとき
動作がどっちになるかわからんってこと？ >>694の心の声
(やべぇ、まじかよ…。バグ仕込んじまった…) 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]
ただ、それを想定するなということなんだろ SwiftってiOSアプリ以外に広がる可能性ある？ 少なくともwillSetがある場合は参照渡しの最適化が掛からないようだね
以下のAはcopy-in, copy-outになっていて、Bは参照渡しになってる
http://swift.sandbox.bluemix.net/#/repl/592977d0d72c2a7516859cca >>696
いやそれ副作用ある状態じゃん
関数終わった時点で
a=1,4
v=1,3,5
だからoutでvがaに上書きされて
1,3,5,2 が出ないといけないはず >>696
var a = [Int]() { willSet{ } } にしたら [1, 3, 5, 2] になるね >>699
aの内容を変更するためにf()にaを渡したのだから、f()の中ではaとvは同じ扱い
なので、inoutの仕様からすれば、>>696の挙動が自然だと思うけど willSetの有無で挙動が変わるのはいただけな
デバッグで混乱する元になる >>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.
コピーされるて書いてあるやん！ >>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
とも書いてある。参照を渡して最適化されると。
それに依存して関数内で参照元にアクセスするなとも書いてあるけど >>705
うん、>>692を誤読してた
動作変わるのは最適化って言わねーよ！
>>696ってほんとに試したんか >>706
Playgroundにコピペして試してみればいいだろ 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.
…最適化と言い張ってるがこれはひどい このぐらいの最適化はやってくれた方がありがたい
参照渡しの方が確実にパフォーマンス上がるし、通常の使い方で副作用もない
副作用があるようなら書き方に問題があるだろ
inoutで受けた変数のオリジナルにアクセスするコードにワーニングぐらい出してくれたら
とも思うけど、まだそこまで面倒は見きれないんだろ
ただ、最適化の恩恵にあずかりたいなら、willSetなんかは入れない方がいいみたいだな >>706
いや最適化だよ
参照渡しにしたとしても、外形的にcopy-in copy-outした場合と全く同じ動作をする場合にだけ、参照渡しに最適化される
ただ、>>696みたいなコード書くとその最適化の前提がぶっ壊れるから絶対するなとリファレンスでも言ってるだけで
リファレンスにはっきりやるなと書いてることをやって壊れたからってそれはプログラマの責任でしょ
まぁ将来的にownershipが入れば>>696みたいなコードもちゃんとコンパイルエラーにしてくれるようになると思うよ 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] willSet/didSetの挙動が怪しすぎるな
バグなのかもな >>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)になるイメージ この挙動を理解してなければ、structにwillSet/didSetを実装してパフォーマンスに意図しない影響を与える可能性があるな >>697
ないっしょ…
なぜSwiftとかいう自己満発展途上言語なんか使ってるかって言ったらApple様ご指定だからってだけだし mutatingはselfをinoutで渡す
a.f() // これは
A.f(&a)() // これと同じ
なので一般のinout引数と同様にmutatingメソッド内のselfもセマンティクス的にはcopy-in copy-out
ただmutatingが暗黙にselfをinoutで渡すって説明はリファレンスには見つけられなかった
リポジトリのdocsに放り込まれてる文書群ではしばしば言及されてるけど 気軽にプロパティ変えたつもりの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: [])]
*/ クラスで実装すれば、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
*/ Swift初期にJavaScriptに似てるからWeb屋が参入してくるとか言ってた人もいたけど全然違うしSwiftはObjective-Cより仕様が複雑になってきたね
でもおかしなコードはコンパイラがビシバシ教えてくれるし仕様を詳しく知らなくてもとりあえずコードを書く事はできるかな？ Swiftけっこう難しい
Objective-Cは形式張っていてコードがやたらと長くなるだけで実はそんなに難しくない >>720
俺もSwift難しい。
structにprotocol適用したり、protocol extensionとか。 詰め込みすぎて開発者のスキルでコードが変わりすぎるのが難点 >>720
C知ってればハードル高くないからなObjCは SwiftとCのどっちがハードル高いかって言ったらCとは言えないけどな
Cのシンタックスをベースにしてる言語は多いから、初学者にSwiftとC
どっちをやった方がいいかって言われたら間違いなくCだわ 初心者にポインターは結構ハードル高いと思うけど
あとメモリ管理にシビアな所とか Cもわからんようなもやしエンジニアが増えると思うと先が思いやられる
ソフト屋もハードウェアに近いプリミティブな部分の理解は必要なんだけとな
そういう意味でCは高級アセンブラ的なバランスがちょうどいい >>726
ポインタが難しいって言ったって、結局ポインタ的なメモリの知識はあった方がデバッグでメモリ周り疑う疑わないに直結するしなぁ。。。 でも今は簡単なゲーム作りたいとかなら特にポインタの知識なくても作れちゃうからなぁ
初心者にC言語でゲーム作ってだと難しいと思うけど、Swiftなら割と簡単
モグラたたきとかジャンケンゲーム程度なら初心者でも2,3日で作れるかも 誰もポインタないと作れないなんて言ってない。
ポインタの知識はトラブった時にトラブルの原因の候補にメモリが上がるか？どう状態かを推測出来るか？ってのに直結する。
ポインタと言うか、メモリの構造を知らなけりゃトラブルの原因として候補にすら上がらない。
下手すれば永延と原因分からないまま、プログラムは未完に終わる。 そんなこと言い出したら究極的にはコンパイラの癖とかハードの特性とかまで知らないとデバッグできないことになる
初心者にそこまで求めるのは余りにも遠い道のりになる そこまで言わんが、初心者と言えどもCPUとメモリの仕組みは理解してからプログラミングは始めて欲しいものだが。
体験して見たいだけなら兎も角、プログラマになりたいんならね。 kotlin nativeがllvm対応してるらしいのでiosでもkotlin使えそう。
となればswiftはもういいかな。 フフってなった
昔、SwiftもLLVMだからどこでも動くって言ってたなぁ
まぁKotlinは頑張ってポーティングしてるようだから
実用性はさておき動くんだろうけど >>722
C言語のソースも、人によって全然違うけどなぁ。
とくに、Headerファイルのマクロ定義によってソースの印象がガラッと変わる。 >>735
Cと比較したらCのがやりたい放題に決まってるだろ…
関数をアドレス指定で直接コールできる言語やぞ…
比較対象がおかしいわ ポインタとか分からんレベルの人にはやりたい放題出来ないがんじがらめの世界の方がいい気はする
柔軟性はObjective-Cで安全性はSwiftなイメージ >>733
Kotlin/Nativeなんてのがあるのね！
知らんかった。JVM無しで動くコードが作れるのかな？ It is not a fully functional release yet,
Kotlin/Nativeがどの程度動くのか？気になる。 >>729
ポインタ分からないって人は、参照型の値型の違いが理解出来なくないか？ 参照型と値型の違いがわからなくても使い方さえ理解できれば簡単なアプリは作れるからな
ある程度の最適化はコンパイラがやってくれるし、ハードの性能も上がってるから、多少の冗長性は無視できる
C言語だとそうはいかない
ポインタを知らないとまずまともなアプリはつくれない
外部のライブラリを利用する場合もポインタの知識は必須になる
ポインタの理解が参照型の理解の助けにはなるだろうけど厳密にはポインタと参照型は同じものでもないし それは、ポインタを知らなくても使い方さえ覚えれば簡単なアプリは作れる、っていっても同じじゃないか？ ポインタの場合は概念を理解しないで使い方だけ覚えるってのはちと無理がある
Swiftの参照型は概念をきっちり理解できなくても、大概動くものは作れるし、変なことやろうとしてもIDEやコンパイラが注意してくれる >>744
じゃなくて、ポインタの概念を理解出来ない人は、参照という概念も理解出来ないって言う意味だけど
挙動で理解出来てるなら、それは理解出来る人だよ >>745
参照を理解できたからとポインタも理解できたとは言えない
大小が逆 そもそも初心者は参照型だ値型だとあまり意識しないんじゃないか
意識しなくてもコードは書ける
Swiftならね >>741
だからObjective-Cはいろいろと素晴らしいと考える人が少なくないんだと思うけどな 今後出現して欲しい本
SwiftプログラマのためのKotlin入門
Androidアプリ作りたいけど、Javaは嫌なんだよなぁ。 >>749
そんな本なくてもswiftの簡単版みたいなもんだから余裕でかける iosもandroidも共通で言えることなんだけどさ、もう一段フレームワークが欲しい。どっちもuiライブラリ止まりで、
全体の管理を行う部分が開発者任せで、正直困る。一画面アプリ止まりならそれでもいいんだけどさ。 ステート管理だけで言えばreactのreduxみたいなやつとか。
あれってファイルの置き場所とかもある程度誘導されるから迷いが減るんだよね。 ソースファイルの置場所も公式に決まってないSwiftに何期待してるのか
まずはSwift Package ManagerとXcodeで共通化することから始めよう 俺もパッケージマネージャが複数あるのが好かんなぁ。
1. Carthage
2. CocoaPods
3. Swift Package Manager
俺は1.がxcodeprojへの変更が少なくて好みだ。
2.はxcodeprojをどう変更してるのかが、見えない。 CocoaPodsはオープンソースだからxcodeprojをどう変更してるかは見えるだろ Swiftとはちょいと違う事で質問です。
UMLモデリングって最近でも使われますか？
使う目的は何でしょう？
1. すでにあるコードの解析
2. これから作成するコードの可視化 そんなこと聞いてどうすんの？ と聞き返したくなるような質問すんな
皆が使ってるなら使ってみようかってことか >>755
まさにこれ。決めてほしい。
それかアップル自身が公式にリファレンスとなるアプリをオープンソースにしてほしい。
react-nativeだとf8appがそれっぽいが。
なんかそれなりの規模のオープンソースアプリないかな。 swift.orgのPackage Managerのページにゴミのようなサンプルはあるけど
自身(SPM)のことしか考えてないから、自分で作った方が良いだろうねぇ
Swift Package Manager
https://swift.org/package-manager/#conceptual-overview
Package.swift作って、Sources, Testsディレクトリ作る
CocoaPods
https://guides.cocoapods.org/syntax/podfile.html
Podfile作る, Sources/*.swiftを参照
Carthage
https://github.com/Carthage/Carthage/blob/master/Documentation/Artifacts.md#cartfile
Carfile作る, Sources/*.swiftを参照
Xcode
上の全部を適当にpodが作った.xcworkspaceのプロジェクトツリーに加える qiitaのKotlin記事を読んでて出くわしたphrase。
Android アプリ開発者であれば普段から英語を読んでいると思いますし、平易な英語なので大きな問題はないと思います。
俺にはComputer関連の英語文章が難しく感じるのだけど、どうなんでしょう？
exressionを式だと理解するのに、随分時間がかかったと思う。 和書にも専門用語は英訳も一緒に載ってること多いから違和感無かったけど、入門してすぐ洋書だとそう感じるかも。 たしかに！
順方向伝搬(forward propagation)って書いてあるね。和書には。
expressionを式、statementを文と訳すのは判ったけど、和書には「式文」
ってのが時々出て来て、これ何を翻訳したんだ？
と不安になる。 そんなあなたに
Regular Expression
はどう訳す regular = いつもの
例：regular customer = 常連、regular coffee = 日々よく飲むコーヒー
regular ¥= 正規 = formal, proper >>772
まあ、情報が入手しずらい時代に苦心して日本語を当てたって感じだ。
Microsoftの文書を読んで、まったく意味がわからんかったのを思い出さしてクレルわぁ。DAO ActiveX Library, RDO ActiveX Libraryに関しての記述を読んで、
さっぱり意味不明だった。和文も、英文も。
サンプルコードを見たら一発で理解できた。 >>771
じゃあ
リベンジ：復讐
を、なんとかしてよ。
あとfeatureをフューチャーって発音するのもなんとかして欲しい。 swiftが言語仕様固まらないうちにkotlinがios対応しちゃうな。 swiftは作る奴の思考によってパラダイムが変わるから他人のコードがストレスになる糞言語
いっそのことclassを消してしまえばいいわ >>782
糞に見えるのなら、三流エンジニアだな。使いこなせない事を棚に上げて、悪態ツイテルだけにしか思えん。
一体どこが糞なんだ？ SwiftとKotlinでちょっと遅延評価リストを比較した
■Kotlin
オンラインコンパイラ： https://try.kotlinlang.org/
val a = generateSequence(0){it+1}
//A 問題なし
println("A: "+ a.take(10).toList() )
//B 問題なし
println("B: "+ a.take(10).map{it*10}.toList() )
//C 問題なし
println("C: "+ a.filter{3<it}.take(10).toList() )
//D 問題なし
println("D: "+ a.map{it*10}.take(10).toList() )
//E 問題なし
println("E: "+ a.map{it*10}.filter{50<it}.take(5).toList() ) swiftは言語仕様固まらないうちにAndroid対応しちゃうバカだからな
kotlinのios対応って何周遅れだよ...対応遅すぎる ■Swift
オンラインコンパイラ： https://swift.sandbox.bluemix.net/
extension Sequence { var array:[Iterator.Element] {get{return map{$0}}} }
let a = sequence(first:0){$0+1}
//A 問題なし
print("A:", a.prefix(10).array )
//B 問題なし
print("B:", a.prefix(10).map{$0*10}.array )
//C 死ぬ
print("C:", a.filter{3<$0}.prefix(10).array )
//C-2 lazy付けたら動く
print("C:", a.lazy.filter{3<$0}.prefix(10).array )
//D 死ぬ
print("D:", a.map{$0*10}.prefix(10).array )
//D-2 lazy付けてもコンパイル不可
print("D:", a.lazy.map{$0*10}.prefix(10).array )
//E
print("E:", a.map{$0*10}.filter{50<$0}.prefix(5).array )
//E-2 lazy付加＋分割で何とか動く
do {
let a2 = a.lazy.map{$0*10}
let a3 = a2.filter{50<$0}
print("E:", a3.prefix(5).array )
} >>786
THX
無限個Sequenceを扱う時には、気をつけます。 >>786
let a = sequence(first:0){$0+1}.lazy
でよくね
ここ書いてる時点で無限sequenceだってわかってるんだから
ambiguous云々言われるのは…まぁ… たしかにこれはガイジ
理由書いてるレスに理由聞くとか新しすぎる >>788
//print("D:", a.map{$0*10}.prefix(10).array )
print("D:", a.map{($0 as Int)*10}.prefix(10).array )
=> D: [0, 10, 20, 30, 40, 50, 60, 70, 80, 90]
修正したらambiguous言わなくなったけど、なんでだ？ スタイリッシュを装ってるが
ときどき地がでて$0とか$1とか書いちゃう田舎者
それがSwift without Cという、表面的な自己満足を実現する言語仕様
という意味では成功してるかもなSwiftは See what’s next.
The new beta of Xcode 9 is now available,
and includes Swift 4 and SDKs used to build apps with the latest innovations and
powerful capabilities in macOS, iOS, watchOS, and tvOS.
おはギャーきたな 2017/05/26 改正民法が成立、「瑕疵担保責任」などシステム開発契約に影響大
欠陥に気付いた時点から1年以内にITベンダーに通知すれば、通知後5年以内は修正や報酬の減額などを求めることできる
Swift3でシステム作って納品する
↓
iOSバージョンが12になる。Swift4が必須になる
↓
客がプロジェクトファイルからアップデート試す。Swift4の必須のエラーが出る。動作の不具合に気づく
↓
気付いた時点から1年以内に通知すれば、5年間無料保証ゲット
↓
つまりSwiftがアップデートするたびに、無償の修正作業を発生するということかな > iOSバージョンが12になる。Swift4が必須になる
ダウト
中途半端な知識でモノを言うもんじゃねぇよww
なお、小賢しいPMはSwiftバージョン上がる度に
最新のXcodeでビルドできないのはアポーのせいなんでwwwってメンテ工数をぶん取る模様 それはお前が決めることじゃない。コンペで「今後欠陥に気付いてから5年間無料保証を請け負うお」を提案できる会社だけが仕事を取れることだけのこと
コンペで競争がおき、それを提案できる会社が出てくるから、それが慣習化していくよ。法でデフォルトで定められた無限保証をわざわざ有限保証にするバカはいない。 開発環境を変えてビルド出来なくなるのをソフトウェアの欠陥とは言わないよ Xcode 9、リファクタリングとプロトコルのスタブ来たな
インデックス作成もサクサクになってる
GitHub統合とMarkdownエディタもいい感じ DoubleWidthの実装がマージされた
https://github.com/apple/swift/pull/9367
Int1024だって作れる
typealias Int128 = DoubleWidth<Int64>
typealias Int256 = DoubleWidth<Int128>
typealias Int512 = DoubleWidth<Int256>
typealias Int1024 = DoubleWidth<Int512> >>805
objc なみに軽くなった？
あとリファクタリングできる？ こんなことやってて意味あんの？
冗談抜きに自己満言語になってきたな
まじで日曜プログラマー専用言語だろもう… 最初から自己満足言語だから
そして、最初から驚くほどアポー信者が食いつかなかった
教祖様が亡くなるとここまで信仰心が薄れるとは思わなかったよな
ところでメモリ管理の文法と機能はどうなってるんだ
諦めたんかいな >>813
さらに今となってはSwift教祖のベジータ親父もいなくなったからな >>813
ownershipのことならはじめから4がターゲットではない
布石は色々打ってるけど >>815
うせやろ・・・4はownershipのABIだけ決めて文法/機能は申し送りなのかいな
確かにStage 2のGoalsに明記はないけどさ、それだけがSwift4の楽しみだったのになぁ
とりあえず、3からの文法互換性はないはずなのでそれで遊ぶか
4 stableまでに転々とする文法と戯れてるわ・・・ 皆さんは、マウスorトラックボール、何を使ってますか？
どれが使いやすいのか… >>817
Logicoolの無線マウス(non bluetooth) 5 button >>818
やはりボタンが多い方が効率的ですかね？ WWDCなのに特に盛り上がってないのは公式のGitHubで既に今後の新機能などが公表されてるから？ ちがう！！もっと真剣になるのだ！
(知名度はあるけどリアルタイム世代はもう少ない) 昔はQiitaとかSlideShareとかで真っ先に投稿するやついたじゃん。
ああいう意識高い系が減ってきたらもう終わりだな。
Swiftなんてもう仲間内でワイワイやるだけの言語になっちゃったじゃん。 iOS/macOS開発者をまとめて仲間内と表現するならそうだろうけど、その範囲を仲間内と言いだしたら、終わってない言語なんて無くないか？ 本来なら
「Androidの第一級開発言語としてSwiftが採用された！」とか
「Web業界でSwiftに注目が集まってる！」とか
「基幹システムでSwift採用の動きが？！」とか
そういう話が出始める時期なのに、肝心なABIが固まってないから後手に回されてる。
それがSwiftの現状。 >>835
Application Binary Interface
ABIが安定してないと以前のSwiftでビルドしたライブラリ(バイナリ)を
最新のSwiftでビルドしたアプリから呼べなかったりする
Swift4で安定化する予定だったけど延期された iosアプリ作るしか能がない言語より
サーバサイドもお得意なkotlinのほうが良い。と思える。 Swiftもサーバサイド作れるだろ
お得意かどうかは知らんけど >>813
いや逆だろ…
真のアポー信者はSwiftなんか見向きもしない
信者ならJobsがNeXTで導入したObjective-Cを選ぶ >>314
俺はベジータがいなくなった時点でそうとう梯子を外された感が強かった。お前が抜けてどうするんだと。 ラトナー今でもコアチームの一員だし、メーリスに出没するし、たまにプロポーザルのレビューマネージャとかもやっとるよ >>839
テイラースイフトだっけ？
kotlinはjavaの資産を使えるけど
swiftはゼロから作んなきゃいけない上に言語仕様も破壊的変更を辞さないから選択肢はないに等しい テイラースイフトが次に何をすればいいかわからないという意味不明な理由で
突然引退表明したのは
Appleへのなんかの恫喝だったのか >>844
破壊的変更も、納得感のあるものだったら、許容されるんちゃうかなぁ。
特にSwift言語仕様も変わるけど、UIKitの冗長なセレクタ表記が改善されて、
俺は、今んところ納得してるけど。 つかabi安定まではβなので
swiftは4からがステーブル >>844
Kotlin Nativeってのもあるんだろ？
こいつは、Java資産使えんだろ？ >>840
原理派：ObjCこそ至上、Swiftはクソ！
新進派：ObjCは古い、Swiftサイコー！
中立派：ObjCもSwiftもイイ！
Apple教もいろんな派閥があるけど新しいモノを兎角推進する新進主義が昔は主流だったのになぁ
iPhoneのディスプレイが4:3から16:9になった時の信者の掌返しはステキだった
あれだけAndroidの16:9ディスプレイはクソと言ってたのに即座に意見変えてやがんの
SwiftはObjCの資産が使えるけど何か問題あるの？ >>851
840は知らないだけの人なんでしょ。
Bridging Header書けば、ObjC使えるのに。 >>852
ObjCで作ったクラスをSwiftが継承するってのもできるのかな？ >>853
多分できそう。
逆にSwiftで作ったクラスをObjCで継承ってのも条件付きでできるらしい。
その条件ってのは、NSObjectを継承しておくこと。 >>851
問題あるっつうか、Objective-Cの資産使う必要あるならわざわざSwift使う必要がないって思う >>852
>>853
>>854
ところでこのやり取りはどういうことなのかな
同じPCを複数の人で共有してる人たちなのかな ただの自己回答じゃね？
Twitterの自己返信みたいな使い方しちゃったんだろ。 >>845
そういう名前のフレームワークがあるんだよアホ。 サーバサイドならPerfectってフレームワークがある IBMが何かウェブ向けフレームワークをOSSで提供してくれる・・・
そんなふうに考えていた時期が俺にもありました https://github.com/matteocrippa/awesome-swift#webserver
スター順でならべると
Perfect ★11,652 https://www.perfect.org/
vapor ★9,904 https://vapor.codes/
Kitura ★5,767 http://www.kitura.io/
Swifton ★2,055
swifter ★2,022
Zewo ★1,671
ウェブフレームワークはPerfect、Vapor、Kituraが三傑やね、いまんとこ サーバサイドにswiftを採用するメリットって何かあるの？
毎年python3みたいなことしてるんでしょ SwiftはAppleがゴリ押してるから存在しているだけの言語だと何度言ったら(以下略 >>870
abiが安定したとしてswiftより良い言語なんてないよ！ お前ら、まだSwiftで消耗してるの？
フリルをSwift 3.0移行した際に対応が大変だった箇所
http://in.fablic.co.jp/entry/2017/05/31/100000 Swiftは４で苦労し５になってさらに苦労する。
おそらく６も７も出るだろうな。
毎年ごくろうさまです >>877
JavaScriptは、ES3で苦労しES5になってさらに苦労だ。
ES6(ES2015), ES7(ES2017)でも同じなんだなぁ。
毎年ご苦労。 Java8への移行は破壊的だったので、Java6, Java7の人は苦労してるんだろうなぁ。 Java8はABI相当にあたるbyte codeフォーマット変わったんじゃなかったけ？
まぁ昔からちょいちょい変わってるから今さら騒ぐことでもない >>878
いやいや、ブラウザ依存のクライアントサイドはそんなに頻繁に移行しねえよ。
開発環境レベルでバージョン移行強制してくるAppleとは違う。
こいつらサポートコンパイラ平気で切り捨てるじゃん。
本当バカだよ。AppleもSwift推してるお前らも。 楽かどうかしゃなくて毎回移行が発生してる事自体がクソだし評価基準が低すぎるんじゃないか >>878
なんか破壊的変更あったっけ？
下位互換性を確保したままだからvarとか残ってるし JSはトランスパイラかますことによって互換性への責務は
トランスパイラ側に負わすことができるようになったので開発者側には影響がなくなった
今周りでJSで互換性に困ってるやつおらんやろ？
Swiftは真似できんけどあまり真似して欲しくはないがな
今はうまく行ってるけど責務が分散しすぎると再び暗黒時代が到来するかもしれんからな 変でいい、変でなきゃダメだ…狂ってなきゃ、逸脱してなきゃ悪魔は殺せない Xcode 9のリリースノートを今更読んでたら
> New Build System
> Xcode 9 includes a new build system written from scratch in Swift.
ってあってワロタ、なんて無茶なことを・・・
まだデフォルトでは無効になってるようだけど面白そうだから誰か人柱になって常用してみてくれよ
あと、ObjCへのSwift機能のバックポートは今回はないのなー
いつも何らかバックポートしてたからそこそこ楽しみにしてたので残念だ リファクタリング機能にObjC -> Swiftの変換機能入ってるらしいな。 >>892
まじで初のAI CEOとして復活してほしいわ。アップルまじで終わりそうじゃないか メモ
var family = "👨"
family += "¥u{200D}👩"
family += "¥u{200D}👧"
family += "¥u{200D}👦"
print(family) >>896
会社がでかくなり過ぎたんかねぇ
それでも傲慢な舵取りがいればうまくやれてただろうけど あいぽん出るまでも十分に落ちぶれてたけどな
またもとに戻ってきただけやん？ 今のiPhoneのデザインと種類、iPadの種類見たら発狂するだろうな ジョブスいてもアップルウォッチとかやってたし
スマホを普及させようって思惑があったからジョブス担ぎ出してたんじゃないの
突破力あっても先のネタがないときはダメなんじゃね 米Yahooの凋落ブリを見れば、Appleだって盤石では無いかもしれん。
Hardwareやってるからって安心じゃ無いと思う。
Kodakだって、Sum Microsystemsだって、今は無いし。 最近はfacebookとmsを見直した。
ライブラリとか開発環境という意味で。
appleもjetbrainにide外注してもいい頃なのかも。 >>906
俺も現実逃避して、RubyでCrowler作ってる。
そんでもって、苦手なJavaScriptをいじってみた。
SwiftやRubyのClassがJavaScriptではコンストラクタ関数なのね。
Classの継承みたいな事もできるのね。
Chef.prototype = new Person();
上記は食堂のシェフさんは、Person()コンストラクタを継承している、ってのを意味する。
ここ２週間でJavaScriptの苦手意識が和らいだ。 >>897
合体文字だね。
グラフィーム・なんちゃらとかいうヤツ。
一文字が、４つのUnicode Code Pointの合成だってのがビックリ。 >>909
u{200D}ゼロ幅接合子、なんてのを初めて知った。
一種の制御文字なのか？ 最近Kotlinの話題ばっか見かけるな。
Swift飽きたのか？Swiftに見切りを付けたのか？ swift学んでもどんどん仕様変わるし、kotlinでいいや。jsのトランスパイラとしても使えて汎用性も高い >>915
kotlinがjsのトランスパイラ？
そんな使い方できるのか？
ES2016をES3に変換とか？ ラトナーがテスラ辞めるらしいね。Appleに戻る事はないよな。 Googleにでも行って腰を落ち着ければいいんじゃないかなぁ！
GoはそんなにLLVMに依存してないからあんまり重宝されそうにないけど
swift.orgかIBMに行ってやっぱりSwiftの発展に貢献するわって言い出したら大笑いする Swiftの初期設計もそうだったけど、ラトナーってあまり先のこと考えずに物事進める人なんかな Turns out that Tesla isn't a good fit for me after all. I'm interested to hear about interesting roles for a seasoned engineering leader!
Chris LatterのTweet
結局テスラには合わんかった。期間限定の技術リーダー職に興味あり！
って言ってるから、行き先がまだ決まらんらしい。 LLVM & Clang rule the world. The present revolution is Swift! I'm looking for a new role as an engineering leader, my resume is easy to find
nondot.org/sabre
Twitterのprofileに新しい職を探してる。履歴書はココ！って書いてある。 >>922
期間限定の技術リーダーってAppleのSwiftのような仕事だろ？
要は好きなように面白いところだけかじってケツフキは他に任せるスタイルかな >>908
ASCII文字のインクリメントと本質的に何か違うの？ いや、ここはJetbrains行ってKotlin担当になるのもあり name:string
型推論がいる場合と､いらない場合ってどうやって見分けるの？ Swiftの型推論は単純だから=で繋いだ右辺から型が推測できる場合に省略可能って判断で良いんじゃないの
右辺で指定した型から後続の処理に依って型を見直すような奇怪な処理はSwiftでは存在しない
func get_name() -> String {
return "Hello World"
}
let name = "Hello World"
let name2 = get_name()
let name3: String // 省略不可
クロージャーパラメータは省略して良い/悪い場合があるけどAppleのReferenceに記述がないな
省略してエラー出たら処置してるけど、振る舞いについて明確な記述があると良いんだけど・・・ しかし、なんでこの時期にobjective-cからswiftにしたんやろ
appleもジョブズ全盛期のiPod、iPhoneの黄金時代にこういう事するならわかるんだけど
（スマホのアプリ開発だったらobjective-cは冗長かもしれないからswiftみたいなのがあった方が
よかったかもしれない）
どっちかってとandroidとかが台頭してきて
apple自体が緩やかに下降してる時期にこういう事しても混乱するだけのような気がする >>932
それだよな。
俺もこれを機会にXamarinなんかのマルチプラットフォームに移行しようかと思ってる。
Swiftは結局Apple DeveloperのCocoa離れを招いただけにしか見えん。 Obj-CはC言語の知識を前提にしてて初心者にはハードルが高かったからな
Swiftは今や教育の現場でも使われてる（Apple談）らしいし
開発者の裾野のを広げたという意味では成功だったんじゃね？ だとしても時期が最悪すぎるkotlinとモロ被りしてるから
なによりswiftが今後も使われ続けるっていう保証が無いのが厳しい
今objective-cでその前例を作ろうとしてるし
なんだかんだ言ってwindowsはずーとc++かc#をメインに据えるつもりだろうし
だから技術者も安心出来るけどobjective-cは話が違うと思う
なによりCocoaのコアはobjective-c使ってんのにわざわざ新規のappleデベロッパが
objective-c使わなくてもいい状態作る意味がよくわからんわ 別にswiftアンチって訳じゃない
なんで今このタイミングでってのが正直な感想
objective-cを排斥したいとかそういう訳じゃないだろうし >>932
ネタがないから言語変えて新しい感出してしのごうとしただけ
いやまじで なんでこのタイミングでって
もう３年たってんだが
モダン言語がもてはやされてる中で旧態依然としたObj-Cは言語的な限界を抱えて
ジリ貧だったし
まぁそれでもObj-Cのサポートもまだやめるとも言ってないし、Swiftが嫌なら、Obj-C使ってればいいだろ
それにMSだって、ベーシック、VB、C++、C#とプッシュする言語を変えたりしてきてるだろ
VBスクリプトとか、JScript とかプッシュに失敗した言語もあるけど そういえば、Visual J++ なんて言語もあったな >>937
それちらっと考えた事あるけどマジだったらappleやばすぎんだろ
なんでよりによって言語に手を出すのかイミフすぎるw
それだったら海外で普及率が高くてcに近いpython（もしくはアンチ多いのは知ってるけどjava）
採用すれば良かったのにpythonのインデントには一長一短あるけどappleがそこらへん改良すればよかったんに >>938
そうはいってもMSの場合はプッシュするけど強制移行ではないだろ
まあappleも別にswift強制してるわけじゃないけどいまのところは >>940
Apple製の独自言語にこだわったんだろ >>941
最初は強制する勢いの事言ってたけどな
多少は現実を見たんだなAppleも >>938
言語的な限界というけど、Objective-CでiOS市場がここまで発展してきた事実がある
Objective-Cが原因で市場の伸びに陰りが見えてきたわけでもなかろう
要するに政治的理由によってSwiftが生まれ、後付けで技術的な理由を与えて
正当化に邁進しているのが今のAppleの姿 ここ数年はKotlinやらファブレットやらウェアラブルやら他社の真似事と後追いでしょ。
社内で長年研究してたとしても公開が遅いと目新しさは無くなるし、昔に比べてAppleが最前線に立って時代を牽引してる感が減った。 せめてabi安定してから正式にリリースするべきだったとは思うね iPhoneはそれまでのスマホを変えたしiPadはそれまでのタブレットを変えただろ？今のAppleにはそういう力が無いように思える。Swiftは世の中にとってのプログラミングというものを変えるのかな。
ちなAppleディスじゃなくてこれからも期待したいって気持ち。 abi安定ってバージョン間の互換性のことじゃないん…？ MusicとかPayとかTVとか後発の上で転けたソリューションはApple多いだろ
なんで言語だけ失敗してると思っちゃってるのか
いつもの失敗事例と理解した上で、信者を煽って儲けるのよ
そして儲け時は3前後で終わった 過去の資産もあるしApple自身がなかなかSwiftに移行出来てないよな。Objective-Cのままコンパライラだけ改良すれば良かったんじゃないのか。 >>950
Objective-C 3.0でよかったと思ってる人は少なくない フレームワークは別にSwiftで書き直す必要はないだろ
Xcode9は、Swiftで書き直されたらしいけど >>935
Carbon APIからCocoa APIに移行した前例はなかった、いいね？
Xcode9はswiftでリメイクされてねーよw
されたのはビルドツールの低レイヤーの一部で、それもまだ試験段階のオプショナル機能で本流は依然C/C++のままだよ モダン言語への移行に文句言ってるのは老害やろ
kotlinでいい？
うむ、特に反論はない
あ、でもおれはプロトコルマンセーだからswiftの方が好きやで ObjC 2.0 = Modern ObjC ってそれ一番言われてるから
モダン() 開発環境のモダナイズにSwiftが貢献したのは確実！
モダン言語には、
Generics、遅延評価、リフレクション、非同期実行、Reactive Extensionが必要だが、Swiftには全部ある。
Obj-Cには幾つかが欠けている。 Obj-Cって､Basicみたいになるの？無くなる？
Swiftって､C#みたいになるの？ 好きな順番
1:Z80 Zilog Assembler
2:SHARP MZ-2Z002
3:Objective-C 2.0
4:TURBO C
5:N88-BASIC V2 好きな順番
N88-BASIC
Visual Basic
Ruby
Swift
JavaScript プログラミング界隈での老害認定は議論にならないから禁止な。
お前ら小飼弾にも老害認定するのかよ。 プログラミングやIT技術と老害は切っても切れないよ
老人は自分の全盛期の知識にしがみつくしか能がないからね 関数型言語の要素を取り入れたのに
SequenceのmapとflatMapの戻り値を遅延評価不可能な配列にしちゃったり
ジェネリックプロトコル型の変数を作れなかったりと
所々野暮ったいSwiftはモダン言語というよりモダンを目指してる言語 iPhone作成の本買ったんだよ
ひと通り勉強して､やっと作成編に行ったんだけど
(acceleDeta:CMAccele!, error:ESError!)in
これが､構造体なのか､タプルなのか何かがわからない
最後の｢!｣ ､これなんだよ >>970
forced unwrappingのマーク >>970
arguments list of closure >>970
どんな本を買ったのか？紹介されたし。
ただ、その程度の理解だと、ソースを読める様になるには、
あと半年掛かりそう。 closureのある言語とは関わりが無かったのか？
JavaScript, Ruby, Obj-C, C#, Java8, Lisp
最近の言語には、皆搭載の機能なんだが！ さすがCよりハードルが低いと豪語するSwift様ですね＾＾ forced unwrapping搭載の言語は、
Rust、Module std::option
TypeScript、 Non-Nullable Types
Python、 UnionTypes
まあ、C言語のUnionだな。 >>975
より安全、柔軟、短く書けるというのは聞くけど
ハードルが低いなんて話あったっけ？
>>970
まず構文をトップダウンで捉えていくこと
クロージャ → 引数 → 型名というように
そして型名に付く「!」はImplicitly Unwrapped Optionalという機能 82歳コンピュータおばあちゃんはSwift使って開発したの？ 雛人形のアプリ作るって､最初から決めてたんで
作れたそうだ swift playgroundとかいうお子ちゃまアプリつかったんかな >>983
Swift Playgroundsアプリデビュー
この本きになる。
誰かレポ頼む 糞アプリなのにババアが作ったというだけで高評価
俺もババアということにしようかな SwiftのUnsafePointe<T>r .memoryってなんでUnsafePointer<T> .pointeeになったんだ？
pointerじゃないのかよ。 int* pointer = ...;
int pointee = *pointer; >>989
employee, employer
adressee, adresser
committee, committer 値渡しだったのかよこれ。letで受け取ってたから気づかなかったわ。 質問があります。
下記のような文をよく見かけます。
var user: User = User() ----(1)
例えば、下記のような書き方もありえますよね。
var person: User = User() ----(2)
(1)が通常の書き方なんですか？ >>994
変数名をどう付けるかというのは状況によるから通常の書き方とかはないんじゃないかな
クラス名を小文字やキャメルケースにしたものを変数名にするときは多いけど、それが原則ってわけでもないし
var employer: User = User()
var employee: User = User()
とかもっと具体的に意味がある名前をつけることだって多いし 通常と例外
一般と特殊
これは、どういった概念なんだ？と俺もかつては思い悩んだ。
変数名、関数名、クラス名、プロトコル名を考えるのって、結構時間かかるから、最初は、a, b, x, yを使って後からフィファクタリングする事も多い。 >>995
ありがとうございました。
よくわかりました。 >>998
わかっててそういうこと言うと嫌われるよ フィファクタリングとか今どき小学生でも知ってるだろ このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
life time: 130日 11時間 4分 55秒 ２ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ ２ちゃんねる専用ブラウザからの広告除去
★ ２ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.2ch.net/
▼ 浪人ログインはこちら ▼
https://login.2ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
