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

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

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

関連スレ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

It is not a fully functional release yet,

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

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

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

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

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

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

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

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

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

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

>>740
ポインタしらなくても挙動でわかるだろ

2017/05/29(月) 13:27:25.51

>>744
じゃなくて、ポインタの概念を理解出来ない人は、参照という概念も理解出来ないって言う意味だけど
挙動で理解出来てるなら、それは理解出来る人だよ

2017/05/29(月) 13:29:35.62

>>745
参照を理解できたからとポインタも理解できたとは言えない
大小が逆

2017/05/29(月) 13:38:22.24

そもそも初心者は参照型だ値型だとあまり意識しないんじゃないか
意識しなくてもコードは書ける
Swiftならね

2017/05/29(月) 21:45:25.45

>>741
だからObjective-Cはいろいろと素晴らしいと考える人が少なくないんだと思うけどな

2017/05/29(月) 21:47:34.02

今後出現して欲しい本

SwiftプログラマのためのKotlin入門

Androidアプリ作りたいけど、Javaは嫌なんだよなぁ。

2017/05/29(月) 21:59:32.56

>>749
そんな本なくてもswiftの簡単版みたいなもんだから余裕でかける

2017/05/30(火) 01:08:42.87

iosもandroidも共通で言えることなんだけどさ、もう一段フレームワークが欲しい。どっちもuiライブラリ止まりで、
全体の管理を行う部分が開発者任せで、正直困る。一画面アプリ止まりならそれでもいいんだけどさ。

2017/05/30(火) 01:09:28.67

？？？

2017/05/30(火) 01:21:48.80

>>751
例えば？

2017/05/30(火) 02:18:06.30

ステート管理だけで言えばreactのreduxみたいなやつとか。
あれってファイルの置き場所とかもある程度誘導されるから迷いが減るんだよね。

2017/05/30(火) 09:52:12.97

ソースファイルの置場所も公式に決まってないSwiftに何期待してるのか
まずはSwift Package ManagerとXcodeで共通化することから始めよう

2017/05/30(火) 10:07:35.91

俺もパッケージマネージャが複数あるのが好かんなぁ。

1. Carthage
2. CocoaPods
3. Swift Package Manager

俺は1.がxcodeprojへの変更が少なくて好みだ。
2.はxcodeprojをどう変更してるのかが、見えない。

2017/05/30(火) 10:49:53.98

CocoaPodsはオープンソースだからxcodeprojをどう変更してるかは見えるだろ

2017/05/30(火) 10:53:32.01

Swiftとはちょいと違う事で質問です。
UMLモデリングって最近でも使われますか？
使う目的は何でしょう？

1. すでにあるコードの解析
2. これから作成するコードの可視化

2017/05/30(火) 11:24:11.63

そんなこと聞いてどうすんの？と聞き返したくなるような質問すんな
皆が使ってるなら使ってみようかってことか

2017/05/30(火) 11:24:54.00

しかるべきスレへ行ってはどうか

2017/05/30(火) 12:41:12.92

>>758
モデリングのために決まってんだろ

2017/05/30(火) 13:35:34.23

>>755
まさにこれ。決めてほしい。
それかアップル自身が公式にリファレンスとなるアプリをオープンソースにしてほしい。
react-nativeだとf8appがそれっぽいが。

なんかそれなりの規模のオープンソースアプリないかな。

2017/05/30(火) 14:59:25.27

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のプロジェクトツリーに加える

2017/05/31(水) 11:13:03.77

qiitaのKotlin記事を読んでて出くわしたphrase。

Android アプリ開発者であれば普段から英語を読んでいると思いますし、平易な英語なので大きな問題はないと思います。

俺にはComputer関連の英語文章が難しく感じるのだけど、どうなんでしょう？
exressionを式だと理解するのに、随分時間がかかったと思う。

2017/05/31(水) 12:18:51.47

和書にも専門用語は英訳も一緒に載ってること多いから違和感無かったけど、入門してすぐ洋書だとそう感じるかも。

2017/05/31(水) 12:45:27.84

たしかに！

順方向伝搬(forward propagation)って書いてあるね。和書には。
expressionを式、statementを文と訳すのは判ったけど、和書には「式文」
ってのが時々出て来て、これ何を翻訳したんだ？

と不安になる。

**デフォルトの名無しさん** (JP 0Hcf-Evzo) · 2017/05/31(水) 16:07:11.28

そんなあなたに
Regular Expression
はどう訳す

2017/05/31(水) 16:13:04.68

>>767
いつも良く使うマッチ式

2017/05/31(水) 16:16:42.72

regular = いつもの
例：regular customer = 常連、regular coffee = 日々よく飲むコーヒー

regular ¥= 正規 = formal, proper

2017/05/31(水) 16:19:06.25

正規表現って訳語は、誤訳だわぁ。

2017/05/31(水) 16:19:30.13

誤訳を永遠と使い続けるのは、よく無い。

**デフォルトの名無しさん** (JP 0Hcf-Evzo) · 2017/05/31(水) 16:25:25.52

>>770
石田晴久が糞って有名ですし

2017/05/31(水) 16:37:31.63

>>772
まあ、情報が入手しずらい時代に苦心して日本語を当てたって感じだ。

Microsoftの文書を読んで、まったく意味がわからんかったのを思い出さしてクレルわぁ。DAO ActiveX Library, RDO ActiveX Libraryに関しての記述を読んで、
さっぱり意味不明だった。和文も、英文も。

サンプルコードを見たら一発で理解できた。

2017/05/31(水) 19:53:48.08

>>771
じゃあ
リベンジ：復讐
を、なんとかしてよ。

あとfeatureをフューチャーって発音するのもなんとかして欲しい。

2017/05/31(水) 20:15:00.41

>>774
頭悪そ。

2017/05/31(水) 21:26:00.22

>>750
Swiftより簡単なの？

2017/05/31(水) 21:33:41.18

>>750
知ったか

2017/05/31(水) 21:47:41.16

>>776
果てしなく簡単

2017/05/31(水) 22:53:30.93

swiftが言語仕様固まらないうちにkotlinがios対応しちゃうな。

2017/05/31(水) 23:40:55.86

Swift使ってる自分が好きな人

2017/06/01(木) 08:38:33.85

モダンな言語Swiftを使ってる最先端な自分

2017/06/01(木) 09:47:53.31

swiftは作る奴の思考によってパラダイムが変わるから他人のコードがストレスになる糞言語
いっそのことclassを消してしまえばいいわ

2017/06/01(木) 10:35:07.17

>>782
糞に見えるのなら、三流エンジニアだな。使いこなせない事を棚に上げて、悪態ツイテルだけにしか思えん。
一体どこが糞なんだ？

2017/06/01(木) 10:53:52.60

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() )

2017/06/01(木) 10:54:14.25

swiftは言語仕様固まらないうちにAndroid対応しちゃうバカだからな
kotlinのios対応って何周遅れだよ...対応遅すぎる

2017/06/01(木) 10:55:55.93

■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 )
}

2017/06/01(木) 11:22:30.68

>>786
THX

無限個Sequenceを扱う時には、気をつけます。

2017/06/01(木) 12:01:04.94

>>786
let a = sequence(first:0){$0+1}.lazy
でよくね
ここ書いてる時点で無限sequenceだってわかってるんだから

ambiguous云々言われるのは…まぁ…

2017/06/01(木) 13:13:36.56

>>783
日本語理解できないガイジ

**デフォルトの名無しさん** (ｽﾌｯ Sd0a-yOWz) · 2017/06/01(木) 13:17:57.99

たしかにこれはガイジ
理由書いてるレスに理由聞くとか新しすぎる

2017/06/01(木) 13:30:11.13

>>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言わなくなったけど、なんでだ？

2017/06/01(木) 21:02:51.03

スタイリッシュを装ってるが
ときどき地がでて$0とか$1とか書いちゃう田舎者
それがSwift

2017/06/05(月) 16:00:36.93

今夜Swift++発表か

2017/06/05(月) 16:32:47.80

また新しい文法が増えるのか

2017/06/05(月) 17:46:21.52

Swift+=1じゃないのか

2017/06/05(月) 18:51:21.00

Swift4なんてなかった

2017/06/05(月) 19:31:26.86

>>795
だな
無駄に++構文無くしたからな

2017/06/05(月) 20:40:53.41

without Cという、表面的な自己満足を実現する言語仕様
という意味では成功してるかもなSwiftは

2017/06/06(火) 09:11:21.70

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/06/06(火) 09:21:00.69

Swift4…。Apple正気か

2017/06/06(火) 09:25:05.11

2017/05/26　改正民法が成立、「瑕疵担保責任」などシステム開発契約に影響大
欠陥に気付いた時点から1年以内にITベンダーに通知すれば、通知後5年以内は修正や報酬の減額などを求めることできる

Swift3でシステム作って納品する
↓
iOSバージョンが12になる。Swift4が必須になる
↓
客がプロジェクトファイルからアップデート試す。Swift4の必須のエラーが出る。動作の不具合に気づく
↓
気付いた時点から1年以内に通知すれば、5年間無料保証ゲット
↓
つまりSwiftがアップデートするたびに、無償の修正作業を発生するということかな

2017/06/06(火) 09:57:12.15

> iOSバージョンが12になる。Swift4が必須になる
ダウト
中途半端な知識でモノを言うもんじゃねぇよww

なお、小賢しいPMはSwiftバージョン上がる度に
最新のXcodeでビルドできないのはアポーのせいなんでwwwってメンテ工数をぶん取る模様

2017/06/06(火) 10:07:42.01

それはお前が決めることじゃない。コンペで「今後欠陥に気付いてから5年間無料保証を請け負うお」を提案できる会社だけが仕事を取れることだけのこと

コンペで競争がおき、それを提案できる会社が出てくるから、それが慣習化していくよ。法でデフォルトで定められた無限保証をわざわざ有限保証にするバカはいない。