[swift-evolution] struct finalization constraint for protocols

[Andrey Volodin via swift-evolution]

Hello everyone!

First of all, I know swift goes into a bit different direction for super type 
safety, but the problem that is going to describe is kind of common to anybody 
who use general purpose library (that are not bound to any big UI/non-UI 
framework).

I’m a game-engine and deep learning developer and I use Swift on the daily 
basis. The thing I think that Swift really misses is struct protocols. Here is 
the basic example. 

Problem: 
Imagine you do a game with some sort of game engine. That game engine is based 
on some math lib and you store all vector data (i.e. positions etc) in the 
something like Point2D from that lib. And then you decided that you need to 
draw a complex polygons in your game. So you search for a triangulation lib. 
And you find it, but it uses its own format to describe points, say 
Triangulation.Point. The thing is that you have a huge buffer of points to 
triangulate, but you need to map every single one of them to that new format of 
that lib and than convert it back. 

Proposal:
Wouldn’t it be nice if we could invent a way to globalize types like that? 

Imagine you declare something like this in your imaginary triangulation library:

final public protocol Vector2D { // or the syntax could be `Vector2D: struct`
var x: Double { get set }
var y: Double { get set }
}

And base the algorithm on this one. So you tell the compiler that we will 
operate on the structs with a known and final layout. Then in your application 
you only need to do:

public extension Point2D: Vector2D {}

Types that will conform to such protocols will have some very strict 
constraints. For example they will have to have the same memory layout (i.e. no 
protocol variables), stored properties in extensions (that are coming soon) 
will be also forbidden for such types. The goal is to decrease the need of 
converting data when you don’t really have to. Those types will have to have 
the same properties, in the same order, all of them must be stored ones.

For example we have a bunch of C libs like OpenCV or dlib and every one of them 
has its own image format. Every single one has own its pixel struct and you 
always need to convert between them. 

I personally think that having something like «type globalization» can improve 
language ecosystem overall and make things more cross-platform. You can think 
of it as a typealiasing but without knowing a type you are aliasing to. The 
compiler will just merge all those types into one during compilation.

Once again: I know this is kind of arguable thing, I just wanted to know your 
opinion on that.

Thanks for your attention,
Andrey Volodin___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Unify the way properties and methods work to make key-value coding more natural

[Andrey Volodin via swift-evolution]

Recently I’ve seen some upcoming changes for #keyPath, but the whole things 
look a bit messy to me. Today I came up with a simple idea of code generation, 
but I thought maybe it would be nice to make this a part of the language?

Look at this code:

public class Foo {
public var a: Int = 0
}

public final class Property {
public var `get`: (U) -> () -> V
public var `set`: (U) -> (V) -> Void

public init(getter: @escaping (U) -> () -> V, setter: @escaping (U) -> (V) 
-> Void) {
self.get = getter
self.set = setter
}
}

// Generated code
public extension Foo {
public static let a: Property = {
return Property(getter: { instance -> (Void) -> Int in
return { return instance.a} },
  setter: { instance -> (Int) -> Void in
return { value -> Void in 
instance.a = value } })
}()
}

let foo = Foo()
foo.a = 5

let _a = Foo.a.get(foo)()
print(_a)

Foo.a.set(foo)(10)
print(foo.a)

The idea is to make properties work the same way the methods work right now. 
That will allow things like tweening properties in the game engine, by simply 
passing the property to some sort of ActionManager.

Of course, this can be achieved by code-generator, but I bet this will be very 
ineffecient in terms of performance. 

The only draw back here from top of my head: It will be impossible to have 
instance- and static- variables with the same name. 

What do you think about this?___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Partial class declaration

[Andrey Volodin via swift-evolution]

There is a lot of talk about stored properties in extensions. But do we really 
need them?

Instead I think we can introduce something like partial classes from C#. It is 
an often case our classes go hell of a big and we have to move some methods to 
dedicated extensions to increase readability. It is also an often case that 
those methods have some stored properties they work with. This is often leads 
to a pattern where we have all stored properties declared in Class.swift and 
then we implement extensions in Class+Something.swift files. 

I bet partial classes should only be available within one module, so you can’t 
extend class from library, etc and work close to text-wide level, just to ease 
the code navigation. That is also will allow some code generation tricks, 
making it easy to create UI/Level designers for Swift. (for example you can 
generate some methods and properties of a Scene class in an editor and mix-in 
that in the user’s project.)

Any thoughts?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution