[swift-evolution] [Proposal Draft] property lists

[Thorsten Seitz]

> Am 11.01.2016 um 18:17 schrieb Matthew Johnson via swift-evolution <swift-evolution at swift.org>:
> 
> These proposals are partly a response to the comments Dave and Joe made about building on more general underlying features.
> 

I am afraid they are not general enough for my taste and leaning too much towards initialization.

Parameter forwarding:
This does not make the language more expressive, i.e. there is no abstraction of the parameter list. I cannot do anything with it except forwarding it. That seems not very useful, it just allows saving some keystrokes which is not really necessary.

Furthermore the syntax is really wrong in my opinion:

// user writes:
func bar(...fooParams) {
    foo(i: 32, ...fooParams)
}

The problem is that I do not see anymore what the API of bar() is! I have to look at method foo() (after scanning the body of bar() to find it) and look there. That’s really bad.

Something like the following (just using some random syntax) would be much better, as it (1) keeps the API of bar() visible and (2) abstracts over the arguments giving us a handle to manipulate it.

func bar(i i: Int, s: String, f: Float = 42, d: Double = 43, b: Bool = false) {
	foo(#arguments.with(i: 32))
	// we can do something with #arguments!
	for (Argument arg in #arguments) {
		print("\(arg.name): \(arg.type) = \(arg.value)“)
	}
}

But then I’m not sure what concrete problems this would solve. Writing out the parameter list is not so bad. I’d wager that in cases of long argument lists a redesign would be better, i.e. by encapsulating groups of parameters into structs or classes (which will probably attract behavior as well in contrast to the property list tuples).
I’d really like to see some concrete examples of use cases where this would be useful and better than refactoring the design.

Partial initializers:
These might have the most merit but are a special case of initialization, so there is nothing gained in general expressivity.

Property Lists:
This is an attempt to solve the problem of the „members“ attribute having to be narrowed for different use cases, like narrowing with regards to var parameters only or with regards to accessibility. Declaring the different views which are required for a specific class or struct explicitly as property list is an interesting solution for that and might possibly be the right thing for a statically safe language. 
What I definitely don’t like is having a partial initializer automatically being created as well. I’m not too fond of automatically created code as that is (a) not visible, (b) therefore not part of the documentation (and even if the documentation gets enriched by explicit entries for automagic functions, which would be nice [the memberwise initializer should be auto-expanded in the documentation, for example], it is still not visible in the source file), and last not least it is (c) not searchable.
Currently I’m thinking the potential problems to be solved with this are not worth the magic (= making the language more difficult and reducing the readability of code).

-Thorsten
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160112/d88a4124/attachment.html>