profile
viewpoint

push eventSwiftGGTeam/ggtalk

Jie Liang

commit sha d6d51752ecdcad59b1dbdd52a85a9db6b6dce5d6

update

view details

push time in 2 hours

push eventSwiftGGTeam/ggtalk

Jie Liang

commit sha 5f26e66288e284946814ef8ad2c8cca62b7d78db

use html in rss

view details

push time in 3 hours

startedSwiftGGTeam/google-swift-style-guide-in-chinese

started time in 5 hours

startedSwiftGGTeam/google-swift-style-guide-in-chinese

started time in 5 hours

push eventSwiftGGTeam/ggtalk

Jie Liang

commit sha 462a74cd5af83118e10ca1d20d3ad6206c854af4

remove talkcdn backup info

view details

push time in 11 hours

push eventSwiftGGTeam/ggtalk

Jie Liang

commit sha 686a1ecd689c668e0283789afbfa00bcd0448ce3

update rss url

view details

Jie Liang

commit sha 39391f684df82eec0526c47c34f18ca865bb8922

add loading

view details

push time in 11 hours

push eventSwiftGGTeam/the-swift-programming-language-in-chinese

tbchen

commit sha 05be6d4ba7b4575b5198e5966d3347757fc01725

修改为正确的超级链接

view details

DanziChen

commit sha 2b715ddb06a57efa086cfdd6b003665608e61c63

Merge pull request #1007 from tbchen/hotfix-links 修改为正确的超级链接

view details

push time in 13 hours

startedSwiftGGTeam/ggtalk

started time in 21 hours

issue closedSwiftGGTeam/the-swift-programming-language-in-chinese

Chapter3-LexicalStructure

Identifiers 节多了一段,下面也多了三个关于 propertywrapper 的标识符 Keywords used in expressions and types 中的rethrows 移到了 Keywords used in declarations 中 全文 -> 右边的文字格式去除斜体 https://docs.swift.org/swift-book/ReferenceManual/LexicalStructure.html

closed time in a day

Nemocdz

push eventSwiftGGTeam/the-swift-programming-language-in-chinese

灰s

commit sha 631a2cbe922bab47c2b41b8b9ca0b9fea10b7cb1

#987 Lexicalstructure (#1006) * 04_Collection_Types 5.1初版 * 校对以后的更新 * 第二次校对以后的修正 * 初次5.1更改 * 装饰改为包装 * 校对以后的更改 * 二次校对 * 5.1更新 * 初次校对后的更改

view details

push time in a day

push eventSwiftGGTeam/SwiftGGTeam.github.io

Deployment Bot (from Travis CI)

commit sha 01ff06717891bb7cd97fe27aade65a2a2f77a593

Deploy SwiftGGTeam/SwiftGGTeam.github.io to github.com/SwiftGGTeam/SwiftGGTeam.github.io.git:master

view details

Forelax

commit sha 82d100c352590838363dd48411655b2a72a21d34

Merge pull request #104 from SwiftGGTeam/master merge stage to master

view details

push time in a day

push eventSwiftGGTeam/GGHexo

Travis CI User

commit sha 39f2bf41733e1bdb6953a6de9c6fc17466c772ee

[skip ci] AUTO: Publish

view details

push time in a day

push eventSwiftGGTeam/source

Travis CI User

commit sha 2d1e390dd98c6a6823062d370ae0506b6966fa3c

AUTO: Publish

view details

push time in a day

push eventSwiftGGTeam/GGHexo

Pancf

commit sha d2b871bb6b77135c806b26e3f6987690faf51b53

add a new article

view details

Pancf

commit sha 6f4c690c548e271c0c0042811386236e189e7ef6

Merge pull request #116 from SwiftGGTeam/stage add a new article

view details

push time in a day

PR merged SwiftGGTeam/GGHexo

add a new article
+247 -0

0 comment

1 changed file

Pancf

pr closed time in a day

PR opened SwiftGGTeam/GGHexo

add a new article
+247 -0

0 comment

1 changed file

pr created time in a day

push eventSwiftGGTeam/SwiftGGTeam.github.io

Deployment Bot (from Travis CI)

commit sha 01ff06717891bb7cd97fe27aade65a2a2f77a593

Deploy SwiftGGTeam/SwiftGGTeam.github.io to github.com/SwiftGGTeam/SwiftGGTeam.github.io.git:master

view details

push time in a day

issue closedSwiftGGTeam/translation

【中】 Chris Lattner on the origins of Swift

title: Chris Lattner on the origins of Swift date: 2019.02.18 tags: categories: permalink: https://oleb.net/2019/chris-lattner-swift-origins/


原文链接= 作者= 原文日期= 译者= 校对= 定稿=

<!--此处开始正文-->

closed time in a day

sfmDev

push eventSwiftGGTeam/translation

Tongzhou Ding

commit sha cccab1dcfcd39e62f39523e1ed1c203370158399

Chris Lattner on the origins of Swift (#222) * Add `oleb.net/crhis-lattner-on-swift.md` * Update header in `oleb.net/crhis-lattner-on-swift.md` * Update `oleb.net/chris-lattner-on-swift.md`. * Update chris-lattner-on-swift.md * Update chris-lattner-on-swift.md * Update chris-lattner-on-swift.md * Update chris-lattner-on-swift.md

view details

push time in a day

PR merged SwiftGGTeam/translation

Chris Lattner on the origins of Swift

下面是 PR 模板,使用说明:

  1. 填上对应的 Issue 链接或者 Issue ID
  2. 填上你认为本文阅读需要的时长
  3. 创建 PR
  4. 可以看到PR Checklist部分变成了可以勾选的方框,按照自己的实际情况进行勾选

这篇文章对应的 Issue 链接是:#212

本文的大致阅读时长:[10 ] 分钟。(这里按照你的主观感受填写即可,不需要非常准确,主要给读者一个参考)

PR Checklist:

  • [x] 我已经仔细阅读 翻译说明文档
  • [x] 我的文章符合 格式要求
  • [x] 我的文章头部符合 头部格式
  • [x] 我已经完成自查环节,从读者角度阅读,我确定文章足够通顺易懂

请校对同学帮忙校对。

+247 -0

0 comment

1 changed file

jojotov

pr closed time in a day

push eventSwiftGGTeam/GGHexo

Pancf

commit sha d2b871bb6b77135c806b26e3f6987690faf51b53

add a new article

view details

push time in a day

MemberEvent

push eventSwiftGGTeam/ggtalk

Jie Liang

commit sha c6b9be89137e116847086ca54014dabac8af1ca1

update rss url

view details

push time in 2 days

Pull request review commentSwiftGGTeam/the-swift-programming-language-in-chinese

#987 Lexicalstructure

 Swift 的*“词法结构(lexical structure)”* 描述了能构成该语言 > *头部标识符* → U+90000–U+9FFFD,U+A0000–U+AFFFD,U+B0000–U+BFFFD,或者 U+C0000–U+CFFFD >  > *头部标识符* → U+D0000–U+DFFFD 或者 U+E0000–U+EFFFD-> -> *标识符字符* → 数值 0 - 9-> -> +>   #### identifier-character {#identifier-character}+>+> *标识符字符* → 数值 0 - 9 >  > *标识符字符* → U+0300–U+036F,U+1DC0–U+1DFF,U+20D0–U+20FF,或者 U+FE20–U+FE2F > -> *标识符字符* → [*头部标识符*](#identifier-head)+> *标识符字符* → [头部标识符](#identifier-head) >  >  #### identifier-characters {#identifier-characters} > -> *标识符字符组* → [*标识符字符*](#identifier-character) [*标识符字符组*](#identifier-characters)<sub>可选</sub>+> *标识符字符组* → [标识符字符](#identifier-character) [标识符字符组](#identifier-characters)<sub>可选</sub> >  >  #### implicit-parameter-name {#implicit-parameter-name} > -> *隐式参数名* → **$** [*十进制数字列表*](#decimal-digit)+> *隐式参数名* → **$** [十进制数字列表](#decimal-digit)+>+#### property-wrapper-projection {#property-wrapper-projection}+>+> *属性包装器投影* → **$** [标识符字符组](#identifier-characters)

属性包装器映射

dzyding

comment created time in 2 days

Pull request review commentSwiftGGTeam/the-swift-programming-language-in-chinese

#987 Lexicalstructure

 Swift 的*“词法结构(lexical structure)”* 描述了能构成该语言 >  #### comment {#comment} > -> *注释* → // [*注释内容*](#comment-text)  [断行符*](#line-break)+> *注释* → // [注释内容](#comment-text)  [断行符](#line-break) >  >  #### multiline-comment {#multiline-comment} > -> *多行注释* → `/*` [*多行注释内容*](#multiline-commnet-text) `*/`+> *多行注释* → `/*` [多行注释内容](#multiline-commnet-text) `*/` >  >  #### comment-text {#comment-text} > -> *注释内容* → [*注释内容项*](#comment-text-item) [*注释内容*](#comment-text)<sub>可选</sub>+> *注释内容* → [注释内容项](#comment-text-item) [注释内容](#comment-text)<sub>可选</sub> >  >  #### comment-text-item {#comment-text-item} > -> *注释内容项* → 任何 Unicode 标量值, 除了 U+000A 或者 U+000D+> *注释内容项* → 任何 Unicode 标量值,除了 U+000A 或者 U+000D >  >  #### multiline-commnet-text {#multiline-commnet-text} > -> *多行注释内容* → [*多行注释内容项*](#multiline-comment-text-item) [*多行注释内容*](#multiline-comment-text)<sub>可选</sub>+> *多行注释内容* → [多行注释内容项](#multiline-comment-text-item) [多行注释内容](#multiline-comment-text)<sub>可选</sub> > -> *多行注释内容项* → [*多行注释*](#multiline-comment).+> *多行注释内容项* → [多行注释](#multiline-comment). > -> *多行注释内容项* → [*注释内容项*](#comment-text-item)+> *多行注释内容项* → [注释内容项](#comment-text-item) > -> *多行注释内容项* → 任何 Unicode 标量值, 除了 `/*` 或者 `*/`+> *多行注释内容项* → 任何 Unicode 标量值,除了 `/*` 或者 `*/`  ## 标识符 {#identifiers} -*标识符(identifier)* 可以由以下的字符开始:大写或小写的字母 `A` 到 `Z`、下划线(`_`)、基本多文种平面(Basic Multilingual Plane)中非字符数字组合的  Unicode 字符以及基本多文种平面以外的非个人专用区字符。在首字符之后,允许使用数字和组合 Unicode 字符。+*标识符(identifier)* 可以由以下的字符开始:大写或小写的字母 `A` 到 `Z`、下划线(`_`)、基本多文种平面(Basic Multilingual Plane)中非字符数字组合的 Unicode 字符以及基本多文种平面以外的非个人专用区字符。在首字符之后,允许使用数字和组合 Unicode 字符。  使用保留字作为标识符,需要在其前后增加反引号(`` ` ``)。例如,`class` 不是合法的标识符,但可以使用 `` `class` ``。反引号不属于标识符的一部分,`` `x` `` 和 `x` 表示同一标识符。  闭包中如果没有明确指定参数名称,参数将被隐式命名为 `$0`、`$1`、`$2` 等等。这些命名在闭包作用域范围内是合法的标识符。 +编译器自动为以美元符号(*$*)开头并且含有属性包装器的属性进行关联。你可以通过代码与这些标识符进行交互,但是不能使用该前缀声明标识符。更详细的介绍,请查看 [特性](./07_Attributes.md) 章节中的 [属性包装器](./07_Attributes.md#propertywrapper) 部分。

编译器给含有属性包装器映射的属性自动合成以美元符号($)开头的标识符。你的代码可以与这些标识符进行交互,

dzyding

comment created time in 2 days

Pull request review commentSwiftGGTeam/the-swift-programming-language-in-chinese

#987 Lexicalstructure

  Swift 的*“词法结构(lexical structure)”* 描述了能构成该语言中有效符号(token)的字符序列。这些合法符号组成了语言中最底层的构建基块,并在之后的章节中用于描述语言的其他部分。一个合法符号由一个标识符(identifier)、关键字(keyword)、标点符号(punctuation)、字面量(literal)或运算符(operator)组成。 -通常情况下,通过考虑输入文本当中可能的最长子串,并且在随后将介绍的语法约束之下,根据随后将介绍的语法约束生成的,根据 Swift 源文件当中的字符来生成相应的“符号”。这种方法称为*“最长匹配(longest match)”*,或者*“最大适合(maximal munch)”*。+通常情况下,符号是根据 Swift 源文件的字符生成的,在随后将介绍的语法约束之下,考虑输入文本中最长可能的子字符串。这种方法称为*“最长匹配(longest match)”*,或者*“最大适合(maximal munch)”*。

符号是考虑了输入文本中最长可能的子字符串,并被随后将介绍的语法约束,根据 Swift 源文件的字符生成的。

dzyding

comment created time in 3 days

Pull request review commentSwiftGGTeam/the-swift-programming-language-in-chinese

#987 Lexicalstructure

 true		    // 布尔值字面量  与单行字符串字面量不同的是,多行字符串字面量可以包含不转义的双引号("),回车以及换行。它不能包含三个未转义的连续双引号。 -""" 之后的回车或者换行开始多行字符串字面量,不是字符串的一部分。 """ 之前回车或者换行结束字面量,也不是字符串的一部分。要让多行字符串字面量的开始或结束带有换行,就在第一行或者最后一行写一个空行。+`"""` 之后的回车或者换行开始多行字符串字面量,它们不是字符串的一部分。结束部分的 `"""` 以及它之前的回车或者换行,也不是字符串的一部分。要让多行字符串字面量的开始或结束带有换行,就在第一行或者最后一行写一个空行。 -多行字符串字面量可以使用任何空格或制表符组合进行缩进;这些缩进不会包含在字符串中。 """ 的结束符号决定了缩进:字面量中的任何一个非空行必须起始于多行字符串字面量结束符号的前面;空格和制表符不会被转换。你可以包在缩进后含额外的空格和制表符;这些空格和制表符会在字符串中出现。+多行字符串字面量可以使用任何空格或制表符组合进行缩进;这些缩进不会包含在字符串中。`"""` 的结束符号决定了缩进:字面量中的每一个非空行都必须以与结束符 `"""` 之前出现的缩进完全相同的缩进开头;空格和制表符不会被转换。你可以在缩进后包含额外的空格和制表符;这些空格和制表符会在字符串中出现。

字面量中的每一个非空行开头都必须与结束符 """ 之前出现的缩进完全一致

dzyding

comment created time in 2 days

Pull request review commentSwiftGGTeam/translation

Chris Lattner on the origins of Swift

+title: "Chris Lattner 讲述 Swift 起源故事"+date: 2019.02.18+tags: [Ole Begemann, Swift]+categories: [Ole Begemann, Swift]+permalink: chris-lattner-swift-origins+keywords: Chris Lattner, Swift, Swift 历史+custom_title: +description: ++---+原文链接=https://oleb.net/2019/chris-lattner-swift-origins/+作者=Ole Begemann+原文日期=2019.02.18+译者=jojotov+校对=+定稿=++<!--此处开始正文-->+++在 [新推出的 Swift 社区播客第一集](https://www.swiftcommunitypodcast.org/episodes/1) 中,[Chris Lattner](http://nondot.org/sabre/), [Garric Nahapetian](https://garricn.com/), 和 [John Sundell](https://www.swiftbysundell.com/) 讲述了关于 Swift 起源的故事和 Swift 社区的现状。++本文是我整理出的一些比较有趣的东西(为了能更好地阅读而做了部分修改)。你可以看到我主要引用了 Chris Lattner 的讲话,因为我认为他对于 Swift 是如何被创造出来的描述是最值得保留下去的。但这并不代表 John 和 Garric 所说的东西没那么有趣。你真的应该去完整地收听整集播客——反正所花的时间和阅读本文相差无几。++<!--more-->++[Swift 社区播客](https://www.swiftcommunitypodcast.org/) 本身也非常值得关注。作为一个让你可以通过各种方式进行贡献的项目,它非常符合我们的预期(上面提到的三位嘉宾在第一集中谈到了更多细节)。在本文的完成过程中,我的工作主要在 [creating the transcript](https://github.com/SwiftCommunityPodcast/podcast/issues/15) 这个 Issue 上进行,甚至在代码格式部分和编辑机器生成的文本部分收到了许多来自于社区的帮助。在此对所有提供过帮助的人表示感谢!++你可以在 GitHub 上找到 [完整的记录副本](https://github.com/SwiftCommunityPodcast/podcast/blob/master/Shownotes/Episode1-Transcript.vtt)([WebVTT 格式](https://en.wikipedia.org/wiki/WebVTT))。所有的播客都是由 [CC-BY 4.0](https://creativecommons.org/licenses/by/4.0/) 授权。++------++## Swift 的起源++*(开始于 16:59)*++> **Crhis Lattner:** 关于这件事,我必须从 [WWDC](https://en.wikipedia.org/wiki/Apple_Worldwide_Developers_Conference) 2010 开始讲起。当时我们刚刚上线了 [Clang](https://en.wikipedia.org/wiki/Clang) 对 [C++](https://en.wikipedia.org/wiki/C%2B%2B) 的支持,非常多的人在这件事上面花费了极其巨大的精力。我对这件事感到非常开心的同时,也有一些烦躁,因为我们做了太多的细节工作。而且你很难不经过思考直接编写 C++ 代码,“天呐,应该有比现在更好的实现方法吧!”+>+> 因此,我与一个叫 [Bertrand Serlet](https://en.wikipedia.org/wiki/Bertrand_Serlet) 的哥们儿进行了许多次讨论。Bertrand 当时是软件团队的老大,同时也是一位出类拔萃的工程师。他是一个令人惊叹的人,并且在语言方面有点极客范。当时他正在推进对 [Objective-C](https://en.wikipedia.org/wiki/Objective-C) 的优化工作。我和他进行了许多次一对一的白板会议。+>+> > At the time, Swift was called ‘Shiny’.+> > 在那时,Swift 还叫 ‘Shiny’+> +> Bertrand 负责苹果公司所有的软件项目,因此他基本没什么时间。但他总是会让我在工作结束时顺便拜访一下他,看他是不是有空。他经常会呆到很晚,然后我们会在白板上进行非常认真的讨论。我们会谈论非常非常多的东西:新语言要达成的目标、一些奇怪的细节如类型系统,并且我们最终都会把这些讨论变成一份计划书。因此我为他做了这份计划书并演变成构建一个新语言的想法。那时这个新语言还叫做 "Shiny",寓意着你正在建造一个 [很酷的](https://www.youtube.com/watch?v=8q_lsRLJhcA) 新东西。[^1] 当然我也是 Firefly 电视节目的粉丝之一。(译者注:"Shiny" 的梗源自 2002 年美国电视节目 [Firefly](https://en.wikipedia.org/wiki/Firefly_(TV_series)),意思相当于真实世界中的 "cool"。)+> +> **John Sundell:** 当时的文件后缀是 `.shiny` 吗?+>+> **Chris Lattner:** 确实没错。你知道在那个时候,这还是个很小型的项目。真的就只有我和 Bertrand 在讨论这件事。另外就只有一个同样非常出色的工程师 [Dave Zarzycki](https://github.com/davezarzycki) 参与了早期的一些概念上的讨论。

确实没错 => 确实如此

jojotov

comment created time in 4 days

Pull request review commentSwiftGGTeam/translation

Chris Lattner on the origins of Swift

+title: "Chris Lattner 讲述 Swift 起源故事"+date: 2019.02.18+tags: [Ole Begemann, Swift]+categories: [Ole Begemann, Swift]+permalink: chris-lattner-swift-origins+keywords: Chris Lattner, Swift, Swift 历史+custom_title: +description: ++---+原文链接=https://oleb.net/2019/chris-lattner-swift-origins/+作者=Ole Begemann+原文日期=2019.02.18+译者=jojotov+校对=+定稿=++<!--此处开始正文-->+++在 [新推出的 Swift 社区播客第一集](https://www.swiftcommunitypodcast.org/episodes/1) 中,[Chris Lattner](http://nondot.org/sabre/), [Garric Nahapetian](https://garricn.com/), 和 [John Sundell](https://www.swiftbysundell.com/) 讲述了关于 Swift 起源的故事和 Swift 社区的现状。++本文是我整理出的一些比较有趣的东西(为了能更好地阅读而做了部分修改)。你可以看到我主要引用了 Chris Lattner 的讲话,因为我认为他对于 Swift 是如何被创造出来的描述是最值得保留下去的。但这并不代表 John 和 Garric 所说的东西没那么有趣。你真的应该去完整地收听整集播客——反正所花的时间和阅读本文相差无几。++<!--more-->++[Swift 社区播客](https://www.swiftcommunitypodcast.org/) 本身也非常值得关注。作为一个让你可以通过各种方式进行贡献的项目,它非常符合我们的预期(上面提到的三位嘉宾在第一集中谈到了更多细节)。在本文的完成过程中,我的工作主要在 [creating the transcript](https://github.com/SwiftCommunityPodcast/podcast/issues/15) 这个 Issue 上进行,甚至在代码格式部分和编辑机器生成的文本部分收到了许多来自于社区的帮助。在此对所有提供过帮助的人表示感谢!++你可以在 GitHub 上找到 [完整的记录副本](https://github.com/SwiftCommunityPodcast/podcast/blob/master/Shownotes/Episode1-Transcript.vtt)([WebVTT 格式](https://en.wikipedia.org/wiki/WebVTT))。所有的播客都是由 [CC-BY 4.0](https://creativecommons.org/licenses/by/4.0/) 授权。++------++## Swift 的起源++*(开始于 16:59)*++> **Crhis Lattner:** 关于这件事,我必须从 [WWDC](https://en.wikipedia.org/wiki/Apple_Worldwide_Developers_Conference) 2010 开始讲起。当时我们刚刚上线了 [Clang](https://en.wikipedia.org/wiki/Clang) 对 [C++](https://en.wikipedia.org/wiki/C%2B%2B) 的支持,非常多的人在这件事上面花费了极其巨大的精力。我对这件事感到非常开心的同时,也有一些烦躁,因为我们做了太多的细节工作。而且你很难不经过思考直接编写 C++ 代码,“天呐,应该有比现在更好的实现方法吧!”+>+> 因此,我与一个叫 [Bertrand Serlet](https://en.wikipedia.org/wiki/Bertrand_Serlet) 的哥们儿进行了许多次讨论。Bertrand 当时是软件团队的老大,同时也是一位出类拔萃的工程师。他是一个令人惊叹的人,并且在语言方面有点极客范。当时他正在推进对 [Objective-C](https://en.wikipedia.org/wiki/Objective-C) 的优化工作。我和他进行了许多次一对一的白板会议。+>+> > At the time, Swift was called ‘Shiny’.+> > 在那时,Swift 还叫 ‘Shiny’+> +> Bertrand 负责苹果公司所有的软件项目,因此他基本没什么时间。但他总是会让我在工作结束时顺便拜访一下他,看他是不是有空。他经常会呆到很晚,然后我们会在白板上进行非常认真的讨论。我们会谈论非常非常多的东西:新语言要达成的目标、一些奇怪的细节如类型系统,并且我们最终都会把这些讨论变成一份计划书。因此我为他做了这份计划书并演变成构建一个新语言的想法。那时这个新语言还叫做 "Shiny",寓意着你正在建造一个 [很酷的](https://www.youtube.com/watch?v=8q_lsRLJhcA) 新东西。[^1] 当然我也是 Firefly 电视节目的粉丝之一。(译者注:"Shiny" 的梗源自 2002 年美国电视节目 [Firefly](https://en.wikipedia.org/wiki/Firefly_(TV_series)),意思相当于真实世界中的 "cool"。)+> +> **John Sundell:** 当时的文件后缀是 `.shiny` 吗?+>+> **Chris Lattner:** 确实没错。你知道在那个时候,这还是个很小型的项目。真的就只有我和 Bertrand 在讨论这件事。另外就只有一个同样非常出色的工程师 [Dave Zarzycki](https://github.com/davezarzycki) 参与了早期的一些概念上的讨论。+>+> 一开始,我们就自然而然地展开了关于内存管理的讨论。当时,我们都确信一点就是:必须要有一个好的方法来解决或改善内存管理,并且我们需要确保 [内存安全](https://docs.swift.org/swift-book/LanguageGuide/MemorySafety.html)。因而,你必须有一个自动内存管理功能。+>+> > 为了达到自动内存管理的目标,我们有史以来第一次以 Swift 的内部设计讨论为起点,并最终在 Objective-C 中实现了此特性。+>+> 首先想到的一个关键功能就是 [ARC](https://clang.llvm.org/docs/AutomaticReferenceCounting.html),同时我们需要让编译器自身支持这个功能,而不是通过运行时来实现。Objective-C 当时使用 [libauto](https://opensource.apple.com/source/libauto/libauto-77.1/README.html) 垃圾回收系统,但它有着一大堆问题。因此为了达到自动内存管理的目标,我们有史以来第一次以 Swift 的内部设计讨论为起点,并最终在 Objective-C 中实现了此特性。随后有许多的东西都是这样产生的,包括 ARC 和 [modules](https://clang.llvm.org/docs/Modules.html) 甚至 [literals](https://clang.llvm.org/docs/ObjectiveCLiterals.html) 及更多类似的功能,它们的确都是由 Swift 的幕后开发主导的。[^2]+>+> **John Sundell:** 所以在当时,你脑海里已经有许多关于 Shiny 的特性,最后它们都在 Swift 中实现了。但你曾经说过,“我们并不想一直等待新语言开发完成。我们应该把这些非常吸引人的特性加入到 Objective-C 中。”+>+> > 在构建一个新的语言时,你必须一直问自己,‘为什么不直接优化现有的语言’,这是幕后构思过程的一部分。+>+> **Chris Lattner:** 或许现在看来,Swift 的出现是必然的,但如果你从另一个角度思考这个问题,在当时并不是所有人都能认识到这一点,甚至连我也不能确定。Bertrand 从过去到现在都一直非常的棒,他一直给予我们极大的鼓励。而且他总是能在质疑中前进。Bertrand 有点类似科学家,他仅仅只是想通过各种途径寻找真相。的确,当时我们有许多疑虑,但同时也有许多好的想法。包括 Bertrand 在内的很多人一直在推进这项工作。在构建一个新的语言时,你必须一直问自己,‘为什么不直接优化现有的语言’,这是幕后构思过程的一部分。而这个问题的答案是,“很显然,我们应该把现有的优化好”。这也是为什么诸如 ARC 的功能会出现。+>+> 但是,在 Swift 中,最需要解决的问题是内存安全。在 Objective-C 中,除非去除 C 相关的东西,不然是不可能达到绝对的内存安全。但去除了 C 的 Objective-C 会失去太多的东西, 而它也不再是 Objective-C 了。+>+> **Garric Nahapetian:** 没错。因此,把一些 Swift 的特性添加到 Objective-C 中就像是 [特洛伊木马](https://zh.wikipedia.org/zh/特洛伊木馬) 一样,可以让大家更容易地信任 Swift ,因为你已经完成了 Objective-C 方面的工作,是这样吗?+> +> **Chris Lattner:** (这里面)其实有许多有趣的内部动力。我觉得我们非常专注地优化 Objective-C 及其相关的平台。对于开发 Swift 而言,这是一种降低风险的办法。如果说,“我们要把所有东西都一次性推到重做”,而且不经过任何测试的话,肯定会有巨大的风险。但如果你只把“少部分”的东西单独推倒重做,比如一个全新的内存管理系统,然后对它进行迭代、调试并结合社区的力量进行开发的话,就只会产生有限的风险。不过有一点我要说的是,不管是外部的社区还是苹果内部的社区,貌似都在对我们说,“为什么你要优先考虑这个?我们就好像是概率论中的 [随机漫步](https://zh.wikipedia.org/wiki/隨機漫步) 一样。为什么你要做这个而不是其他的?”因此,这也成为了一个有趣的动力。++------++## 初始团队的成长++*(开始于 22:49)*++> **Chris Lattner:** 苹果拥有着一支非常强大的工程师队伍。那时有非常多的人一起维护 Objective-C,这其实是有点固执的一件事,但同时这也让我们在动态库、应用和其他类似的东西上拥有了十足的深度和背景。正因如此,那时有许多关于优化 Objective-C 的想法涌现。自从乔布斯离开并创立 [NeXT](https://en.wikipedia.org/wiki/NeXT) 之后,许多杰出的人物都一直参与这项工作并写下了大量相关的白皮书。因此,Objective-C 背后有一个极其庞大的社区在推动着。+>+> 当时,我和 Bertrand 以及 Dave 讨论过一些想法,我也开始着手编写一个编译器的原型。不过结果很显然,我很难靠自己去构建出所有的东西。所以最后的事情也理所当然地发生了——大约在 2011 年四月的时候我们与管理层讨论了关于 Swift 的事情,然后也获得批准去调动一小部分人员。[Ted Kremenek](https://twitter.com/tkremenek)、[Doug Gregor](https://twitter.com/dgregor79)、[John McCall](https://twitter.com/pathofshrines) 以及一些其他的杰出工程师都是在那时调入 Swift 项目的。现在回头看看,其实挺有意思的,因为当时是第一次有一些语言和设计专家对 Swift 做了批判性的评价。他们反馈了很多严厉的批判。虽然他们的本意并不是打击我们,但他们的确说的很对——这个语言当时实在是糟透了。+>+> 能让这一切顺利进行有一个关键原因,就是我们有机会拉拢一位泛型领域的世界级专家,以及一支构建过 Clang 编译器的团队。同时这支团队也参与过许多不同的有意思的项目,并能够尽可能地发挥他们的工程天赋。虽然他们只是帮助推进和开发构建的一部分人员,但却至关重要。+>+> **John Sundell:** 在那时 Swift 语言的状况是怎样的?比如,语言的语法是什么样子?编译器的哪部分基础设施已经搭建完成了?它是不是已经接近于原型的阶段甚至更进一步呢?+>+> **Chris Lattner:** 那时 Swift 已经非常接近原型阶段了。这些资料都是完全公开的,因为在 GitHub 上,[变更历史是完全公开](https://github.com/apple/swift/commits/master) 的。[变更日志](https://github.com/apple/swift/blob/master/CHANGELOG.md) 虽然不能完全追溯所有的历史变更,但已经足够了。+>+> 在 Doug 加入之前,Swift 并没有泛型系统。当时我们很想做一个泛型系统,但我不是很有自信能独自设计出来,Doug 却做到了。我记得在很早的时候,John 曾经接手过一个项目,让一个类似语法分析器的东西变得可以真正生成代码。Doug 所做的事情大概就是这样。+>+> 有很多零碎的事情我不太记得了,但有些东西我却一直记忆犹新。我记得 `var` 和 `func` 就是从最初就制定好的。早期的 Swift 中很多基本语法都和现在的 Swift 语法非常接近。+>+> > 当你构建一样新东西的时候,通常想法是领先于文档的,而文档又先于代码。我们当时情况也非常类似。到现在,想法已经领先于代码非常之多了,这都是无可避免的。+>+> 当时的 Swift 已经十分接近于一个原型了。但仍有许许多多的想法未实现。当你构建一样新东西的时候,通常想法是先于文档的,而文档又是先于代码。我们当时情况也非常类似。到现在,想法已经领先于代码非常之多了,这都是无可避免的。++------++## 关于 Craig Federighi++*(开始于 26:10)*++> **Chris Lattner:** 对于社区非常重要的另一位伙伴名叫 [Craig Federighi](https://en.wikipedia.org/wiki/Craig_Federighi)。Craig 在苹果社区中非常出名。在 2011 年早些时候,他加入了这个项目。那时正好 Bertrand 从苹果退休,Craig 便接手了他的工作。+>+> 说到 Craig,他是一个非常、非常有趣的人。无论在台上还是台下,他都着非凡的个人魅力。大多数人们都不了解他到底有多么的聪明。他还在许多方面都有着极其深入的研究。我完全没想到,他在语言方面懂得很多。他曾为 [Groovy](http://groovy-lang.org/) 和许多其他类型的语言作为正式参与者工作过,有些语言我甚至还没接触过。而且,他并不像是一位只会谈论策略的高层人员。他同样关心许多细节的事情,例如闭包语法、关键字和其他东西。+>+> Craig 真的是一位非常严格的任务推动者,同时他也推动着 Swift 的实现以及 Swift 与 Objective-C 的联动。不仅如此,他还关心着 Objective-C 本身的维护;关心着 API;关心着 Objective-C 的 API [导入到 Swift](https://github.com/apple/swift-evolution/blob/master/proposals/0005-objective-c-name-translation.md) 后的形态,还有相关的一切。Craig 在积极给予反馈的同时,一直保持着在团队和项目上出乎意料的卓越态度。他的帮助对 Swift 的现状影响很大。+>+> **Garric Nahapetian:** 这真的很酷,因为他刚好是在 WWDC 2014 的讲台上第一位发表演讲的人。+>+> **Chris Lattner:** 没错。+>+> **John Sundell:** 然后他就介绍你出场了,对吧?我还记得那句经典的标语:“没有 C 的 Objective-C”。+>+> > 我对那句“没有 C 的 Objective-C”标语有着复杂的感觉,因为其实我想表达的并不是这样。+>+> **Chris Lattner:** 说实话,我对那句标语有着复杂的感觉,因为其实我想表达的并不是这样。+>+> **John Sundell:** 那是句很棒的标语。+>+> **Chris Lattner:** 在那个时候,以这种方式向社区宣传是很正确的选择。+>+> (……)+>+> > 在项目的一开始,我的目标其实是构建一个全栈系统。+>+> **Chris Lattner:** 至于说为什么我当时很矛盾,因为在项目的一开始,我的目标其实是构建一个全栈系统——分析市面上现有的系统,取其精华,弃其糟粕。而且当时的目标是构建一个可以编写固件、编写脚本、编写移动应用和服务端应用甚至是更底层系统代码的语言,同时在语言层面上并非只是通过随意堆砌来实现,我要让它在上面说的所有方面都能表现出色。+> +> 所以在当时而言,这个方向绝对是正确的。虽然目前 Swift 还没能达到预期,但欣慰的是它的发展将会使它能够在未来拥有这些的能力。++------++## 文档的重要性++*(开始于 30:32)*++> **Chris Lattner:** (在这里)我还要最后提到一支团队。你目前所看到的 Swift,它是一个[编译器](https://en.wikipedia.org/wiki/Compiler),是一门语言,是[一系列 API 的集合](https://developer.apple.com/documentation/swift/swift_standard_library),也是一个 IDE。但让这些事情能够成真,并让 Swift 走向大众,离不开开发者发布团队的工作。他们是 Apple 的科技编辑,负责编写如 [Swift 编程语言书籍](https://developer.apple.com/documentation/swift/swift_standard_library) 之类的东西。Swift 的成功和快速适应市场离不开当时第一时间发布的高质量文档和书籍。直到今天,他们仍在维护这些文档,真的非常不可思议。+>+> > 我们直接把这些科技编辑拉入了设计讨论会+>+> 我记得当时我们直接把这些科技编辑拉入了设计讨论会。像 [Tim Isted](https://twitter.com/timisted)、Brian Lanier 和 Alex Martini 这些人,他们在周会上花了大量的时间争论着一些细节问题——“我们是否应该使用点语法?”“我们应该使用这个关键字还是那个关键字?”或者是“我们是应该把 `func` 改为 `def` 吗?”同时还讨论着——类型系统的深度以及 [代码生成]([codegen](https://en.wikipedia.org/wiki/Code_generation_(compiler)) 算法应如何工作;我们如何达到较好的性能?[字符串](https://developer.apple.com/documentation/swift/string) 应如何运作?还有各种各样的问题。

image

这个地方链接样式有问题,需要调整

jojotov

comment created time in 4 days

Pull request review commentSwiftGGTeam/translation

Chris Lattner on the origins of Swift

+title: "Chris Lattner 讲述 Swift 起源故事"+date: 2019.02.18+tags: [Ole Begemann, Swift]+categories: [Ole Begemann, Swift]+permalink: chris-lattner-swift-origins+keywords: Chris Lattner, Swift, Swift 历史+custom_title: +description: ++---+原文链接=https://oleb.net/2019/chris-lattner-swift-origins/+作者=Ole Begemann+原文日期=2019.02.18+译者=jojotov+校对=+定稿=++<!--此处开始正文-->+++在 [新推出的 Swift 社区播客第一集](https://www.swiftcommunitypodcast.org/episodes/1) 中,[Chris Lattner](http://nondot.org/sabre/), [Garric Nahapetian](https://garricn.com/), 和 [John Sundell](https://www.swiftbysundell.com/) 讲述了关于 Swift 起源的故事和 Swift 社区的现状。++本文是我整理出的一些比较有趣的东西(为了能更好地阅读而做了部分修改)。你可以看到我主要引用了 Chris Lattner 的讲话,因为我认为他对于 Swift 是如何被创造出来的描述是最值得保留下去的。但这并不代表 John 和 Garric 所说的东西没那么有趣。你真的应该去完整地收听整集播客——反正所花的时间和阅读本文相差无几。++<!--more-->++[Swift 社区播客](https://www.swiftcommunitypodcast.org/) 本身也非常值得关注。作为一个让你可以通过各种方式进行贡献的项目,它非常符合我们的预期(上面提到的三位嘉宾在第一集中谈到了更多细节)。在本文的完成过程中,我的工作主要在 [creating the transcript](https://github.com/SwiftCommunityPodcast/podcast/issues/15) 这个 Issue 上进行,甚至在代码格式部分和编辑机器生成的文本部分收到了许多来自于社区的帮助。在此对所有提供过帮助的人表示感谢!++你可以在 GitHub 上找到 [完整的记录副本](https://github.com/SwiftCommunityPodcast/podcast/blob/master/Shownotes/Episode1-Transcript.vtt)([WebVTT 格式](https://en.wikipedia.org/wiki/WebVTT))。所有的播客都是由 [CC-BY 4.0](https://creativecommons.org/licenses/by/4.0/) 授权。++------++## Swift 的起源++*(开始于 16:59)*++> **Crhis Lattner:** 关于这件事,我必须从 [WWDC](https://en.wikipedia.org/wiki/Apple_Worldwide_Developers_Conference) 2010 开始讲起。当时我们刚刚上线了 [Clang](https://en.wikipedia.org/wiki/Clang) 对 [C++](https://en.wikipedia.org/wiki/C%2B%2B) 的支持,非常多的人在这件事上面花费了极其巨大的精力。我对这件事感到非常开心的同时,也有一些烦躁,因为我们做了太多的细节工作。而且你很难不经过思考直接编写 C++ 代码,“天呐,应该有比现在更好的实现方法吧!”+>+> 因此,我与一个叫 [Bertrand Serlet](https://en.wikipedia.org/wiki/Bertrand_Serlet) 的哥们儿进行了许多次讨论。Bertrand 当时是软件团队的老大,同时也是一位出类拔萃的工程师。它是一个令人惊叹的人,并且在语言方面有点极客范。当时他正在推进对 [Objective-C](https://en.wikipedia.org/wiki/Objective-C) 的优化工作。我和他进行了许多次一对一的白板会议。+>+> > At the time, Swift was called ‘Shiny’.+> > 在那时,Swift 还叫 ‘Shiny’+> +> Bertrand 负责苹果公司所有的软件项目,因此他基本没什么时间。但他总是会让我在工作结束时顺便拜访一下他,看他是不是有空。他经常会呆到很晚,然后我们会在白板上进行非常认真的讨论。我们会谈论非常非常多的东西:新语言要达成的目标、一些奇怪的细节如打字系统,并且我们最终都会把这些讨论变成一份计划书。因此我为他做了这份计划书并演变成构建一个新语言的想法。那时这个新语言还叫做 "Shiny",寓意着你正在建造一个 [很酷的](https://www.youtube.com/watch?v=8q_lsRLJhcA) 新东西。[^1] 当然我也是 Firefly 电视节目的粉丝之一。(译者注:"Shiny" 的梗源自 2002 年美国电视节目 [Firefly](https://en.wikipedia.org/wiki/Firefly_(TV_series)),意思相当于真实世界中的 "cool"。)+> +> **John Sundell:** 当时的文件后缀是 `.shiny` 吗?+>+> **Chris Lattner:** 确实没错。你知道在那个时候,这还是个很小型的项目。真的就只有我和 Bertrand 在讨论这件事。另外就只有一个同样非常出色的工程师 [Dave Zarzycki](https://github.com/davezarzycki) 参与了早期的一些概念上的讨论。+>+> 一开始,我们就自然而然地展开了关于内存管理的讨论。当时,我们都确信一点就是:必须要有一个好的方法来解决或改善内存管理,并且我们需要确保 [内存安全](https://docs.swift.org/swift-book/LanguageGuide/MemorySafety.html)。因而,你必须有一个自动内存管理功能。+>+> > 为了达到自动内存管理的目标,我们有史以来第一次以 Swift 的内部设计讨论为起点,并最终在 Objective-C 中实现了此特性。+>+> 首先想到的一个关键功能就是 [ARC](https://clang.llvm.org/docs/AutomaticReferenceCounting.html),同时我们需要让编译器自身支持这个功能,而不是通过运行时来实现。Objective-C 当时使用 [libauto](https://opensource.apple.com/source/libauto/libauto-77.1/README.html) 垃圾回收系统,但它有着一大堆问题。因此为了达到自动内存管理的目标,我们有史以来第一次以 Swift 的内部设计讨论为起点,并最终在 Objective-C 中实现了此特性。随后有许多的东西都是这样产生的,包括 ARC 和 [modules](https://clang.llvm.org/docs/Modules.html) 甚至 [literals](https://clang.llvm.org/docs/ObjectiveCLiterals.html) 及更多类似的功能,它们的确都是由 Swift 的幕后开发主导的。[^2]+>+> **John Sundell:** 所以在当时,你脑海里已经有许多关于 Shiny 的特性,最后它们都在 Swift 中实现了。但你曾经说过,“我们并不想一直等待新语言开发完成。我们应该把这些非常吸引人的特性加入到 Objective-C 中。”+>+> > 在构建一个新的语言时,你必须一直问自己,‘为什么不直接优化现有的语言’,这是幕后构思过程的一部分。+>+> **Chris Lattner:** 或许现在看来,Swift 的出现是必然的,但如果你从另一个角度思考这个问题,在当时并不是所有人都能认识到这一点,甚至连我也不能确定。Bertrand 从过去到现在都一直非常的棒,他一直给予我们极大的鼓励。而且他总是能在质疑中前进。Bertrand 有点类似科学家,他仅仅只是想通过各种途径寻找真相。的确,当时我们有许多疑虑,但同时也有许多好的想法。包括 Bertrand 在内的很多人一直在推进这项工作。在构建一个新的语言时,你必须一直问自己,‘为什么不直接优化现有的语言’,这是幕后构思过程的一部分。而这个问题的答案是,“很显然,我们应该把现有的优化好”。这也是为什么诸如 ARC 的功能会出现。+>+> 但是,在 Swift 中,最需要解决的问题是内存安全。在 Objective-C 中,除非去除 C 相关的东西,不然是不可能达到绝对的内存安全。但去除了 C 的 Objective-C 会失去太多的东西, 而它也不再是 Objective-C 了。+>+> **Garric Nahapetian:** 没错。因此,把一些 Swift 的特性添加到 Objective-C 中就像是 [特洛伊木马](https://zh.wikipedia.org/zh/特洛伊木馬) 一样,可以让大家更容易地信任 Swift ,因为你已经完成了 Objective-C 方面的工作,是这样吗?+> +> **Chris Lattner:** (这里面)其实有许多有趣的内部动力。我觉得我们非常专注地优化 Objective-C 及其相关的平台。对于开发 Swift 而言,这是一种降低风险的办法。如果说,“我们要把所有东西都一次性推到重做”,而且不经过任何测试的话,肯定会有巨大的风险。但如果你只把“少部分”的东西单独推倒重做,比如一个全新的内存管理系统,然后对它进行迭代、调试并结合社区的力量进行开发的话,就只会产生有限的风险。不过有一点我要说的是,不管是外部的社区还是苹果内部的社区,貌似都在对我们说,“为什么你要优先考虑这个?我们就好像是概率论中的 [随机漫步](https://zh.wikipedia.org/wiki/隨機漫步) 一样。为什么你要做这个而不是其他的?”因此,这也成为了一个有趣的动力。++------++## 初始团队的成长++*(开始于 22:49)*++> **Chris Lattner:** 苹果曾经拥有着一支非常强大的工程师队伍。那时有非常多的人一起维护 Objective-C,这其实是有点固执的一件事,但同时这也让我们在动态库、应用和其他类似的东西上拥有了十足的深度和背景。正因如此,那时有许多关于优化 Objective-C 的想法涌现。自从乔布斯离开并创立 [NeXT](https://en.wikipedia.org/wiki/NeXT) 之后,许多杰出的人物都一直参与这项工作并写下了大量相关的白皮书。因此,Objective-C 背后有一个极其庞大的社区在推动着。

修改:删除 “曾经”

jojotov

comment created time in 4 days

issue commentSwiftGGTeam/translation

【长】Using Swift Protocols to Manage App Configuration

突然来了一大波需求,搞不了这个了,我再处理一篇 Swift 5.1 的翻译吧

Nemocdz

comment created time in 6 days

push eventSwiftGGTeam/the-swift-programming-language-in-chinese

Jie Liang

commit sha 11aa5ab0d6aa674b32655305fc8c3f155d239d98

fix anchor name and link format

view details

push time in 6 days

push eventSwiftGGTeam/the-swift-programming-language-in-chinese

Licardo

commit sha 028a6aa79546abc6a395e865c6667b600bdd7e38

修改文档名称及顺序,与官方文档保持一致 (#1005)

view details

push time in 6 days

pull request commentSwiftGGTeam/the-swift-programming-language-in-chinese

修改文档名称及顺序,与官方文档保持一致

@numbbbbb 这次应该没问题了吧

L1cardo

comment created time in 6 days

pull request commentSwiftGGTeam/the-swift-programming-language-in-chinese

修改文档名称及顺序,与官方文档保持一致

这种方式不能解决冲突。先 git pull upstream 更新源库,执行完会提示你哪几个文件冲突,修改好之后 git add 然后 git commit。不行就再找一些相关资料看看。

L1cardo

comment created time in 7 days

pull request commentSwiftGGTeam/the-swift-programming-language-in-chinese

修改文档名称及顺序,与官方文档保持一致

@numbbbbb 我已经修改了,将内部的跳转链接全都改完了。 由于文件改名字了,且昨天又有新的改动,所以还是提示有conflict,但是我已经将昨天的改动也加进去了,看一下吧

L1cardo

comment created time in 7 days

issue closedSwiftGGTeam/the-swift-programming-language-in-chinese

Swift教程 -> 字符串和字符 -> 拓展字符串分隔符 小结中 使用了中文的"和#

文档链接 如果需要字符串文字中字符的特殊效果,请匹配转义字符(\)后面添加与起始位置个数相匹配的 # 符。 例如,如果您的字符串是 #"Line 1 \nLine 2"# 并且您想要换行,则可以使用 #“Line 1 #nLine 2”# 来代替。 同样,###"Line1 ###nLine2"### 也可以实现换行效果。

注意加粗部分

closed time in 7 days

313183373

issue closedSwiftGGTeam/the-swift-programming-language-in-chinese

Swift 教程 -> 基础部分 -> 可选绑定 小结 翻译与原文不一致

文档链接 翻译部分: 你可以包含多个可选绑定或多个布尔条件在一个 if 语句中,只要使用逗号分开就行。只要有任意一个可选绑定的值为 nil,或者任意一个布尔条件为 false,则整个 if 条件判断为 false,这时你就需要使用嵌套 if 条件语句来处理,如下所示:

删除线部分内容在原文中并不存在,而且放在这里逻辑也不通。

原文: You can include as many optional bindings and Boolean conditions in a single if statement as you need to, separated by commas. If any of the values in the optional bindings are nil or any Boolean condition evaluates to false, the whole if statement’s condition is considered to be false. The following if statements are equivalent:

closed time in 7 days

313183373

push eventSwiftGGTeam/the-swift-programming-language-in-chinese

Jie Liang

commit sha 8f53cc7d82eb8966e998dabc8d610b834e50178a

fix wrong translation, ref #1003

view details

Jie Liang

commit sha 4dcdd13e748a9ff1e4fc5503b15219b52368b855

use english punctuation, ref #1004

view details

push time in 7 days

more