这里不说太多语法方面的东西，也不提cocoa。
var和let
了解OC的人可能知道，var和let都是堆上的一个对象，它们在作用域的末尾被ARC释放。你说它们都是OC中的指针吗？它们可以直接传给OC写的函数，显然它们是，或者至少能隐式的转换成一个指针。你也可以把它们传给一个UnsafePointer类型，显然它们就是一个指针了。（你可以用这种办法获得一个闭包的地址！只需要将它传给一个COpaquePointer类型，这几乎是swift刚出的时候所有需要使用函数指针的人的套路）。所以，不管它们是什么类型，我们就当作它们是一个更加安全的指针吧。
编译器看到它们会怎么处理？我并没有看过语法树的组成，但是显然会有一个字段用来区分它们。但是运行库是否保障了它们的不变性？这就要靠实验了。
类型推断又是怎么处理呢？显然，一个var对象里还有一个类型字段，我的看法是init方法不仅返回了一个对象，还返回了一个类型字段，或者对象本身带有类型字段。var对象在接收这个对象后，便给自己的类型字段赋值，就和具名类型没什么区别了。
值类型与引用类型
显然结构和元组们都隐含了一个基类，这个手段已经被用了无数次了，不再叙述。但是枚举则比较特殊，它可以指定类型，这应该是因为一个类型字段导致的。
它们的赋值号经过了特殊处理而进行了拷贝。而引用类型显然只是返回了一个浅表副本。自然有一个隐藏的方法存在。
方法
闭包们难以获取地址，这让两个闭包的比较变得十分困难。显然，现代对方法的描述应该包括返回值，方法签名和方法体。OC中有一selector和IMP指针就是用于描述它们的。很多人仿照C#“发明”了一个C#中的委托，用来保证闭包的可使用性。Swift中也有这些方法信息，但是显然编译器比我们了解的更多--这几个对象相当不透明，甚至于没有暴露任何东西。很多人直接打印这些对象来欺骗编译器，最终证实了这一点：swift描述方法的方式与OC相同，这使得他们能够互相理解。也使得swift可以直接套用cocoa的运行环境。
然而 swift在实现中有一些不合常理的地方，这也使得OC很难理解有些swift的表达。这将在之后描述。
var和let
了解OC的人可能知道，var和let都是堆上的一个对象，它们在作用域的末尾被ARC释放。你说它们都是OC中的指针吗？它们可以直接传给OC写的函数，显然它们是，或者至少能隐式的转换成一个指针。你也可以把它们传给一个UnsafePointer类型，显然它们就是一个指针了。（你可以用这种办法获得一个闭包的地址！只需要将它传给一个COpaquePointer类型，这几乎是swift刚出的时候所有需要使用函数指针的人的套路）。所以，不管它们是什么类型，我们就当作它们是一个更加安全的指针吧。
编译器看到它们会怎么处理？我并没有看过语法树的组成，但是显然会有一个字段用来区分它们。但是运行库是否保障了它们的不变性？这就要靠实验了。
类型推断又是怎么处理呢？显然，一个var对象里还有一个类型字段，我的看法是init方法不仅返回了一个对象，还返回了一个类型字段，或者对象本身带有类型字段。var对象在接收这个对象后，便给自己的类型字段赋值，就和具名类型没什么区别了。
值类型与引用类型
显然结构和元组们都隐含了一个基类，这个手段已经被用了无数次了，不再叙述。但是枚举则比较特殊，它可以指定类型，这应该是因为一个类型字段导致的。
它们的赋值号经过了特殊处理而进行了拷贝。而引用类型显然只是返回了一个浅表副本。自然有一个隐藏的方法存在。
方法
闭包们难以获取地址，这让两个闭包的比较变得十分困难。显然，现代对方法的描述应该包括返回值，方法签名和方法体。OC中有一selector和IMP指针就是用于描述它们的。很多人仿照C#“发明”了一个C#中的委托，用来保证闭包的可使用性。Swift中也有这些方法信息，但是显然编译器比我们了解的更多--这几个对象相当不透明，甚至于没有暴露任何东西。很多人直接打印这些对象来欺骗编译器，最终证实了这一点：swift描述方法的方式与OC相同，这使得他们能够互相理解。也使得swift可以直接套用cocoa的运行环境。
然而 swift在实现中有一些不合常理的地方，这也使得OC很难理解有些swift的表达。这将在之后描述。
楼主需要去重读初中语文。
