Just to clarify. Swift does have reflection capabilities. Things like type(of:), dump(), and Mirror all use the reflection stuff that is built into the runtime. The issue is a lot of the useful type metadata is not currently exposed in Swift proper.
From what I've heard from the runtime gurus working on the compiler, it's feasible that better support for accessing this stuff will come in the future when the layout of the type metadata becomes ABI stable. Once that happens it's entirely possible to start casting .Type values to pointers and doing all the magic reflection stuff. You can do that now, but it's subject to breakage at anytime.
It doesn't look like any of those options let you find a type by name at runtime or get a list of all of the types in a given binary at runtime. In C# you can load a new assembly (a .dll), list its defined types, and then create an instance of one of those types, all without your code ever knowing about that type ahead of time.
In Swift you could use a custom protocol, but that would only work if the type you're loading implements the same protocol your code was written against. That's why standardization for this common basic requirement (something that can be initialized with no arguments) is useful. It would allow more interoperability for these use cases instead of a bunch of ad hoc versions.
This gives the default value in contexts where you have a concrete type, which is fine. Once you add it to a protocol, however, you're now in a generic context and the question of what the semantics of this default value are become key. What generic algorithms are you going to write using DefaultInit? This is the heart of the fundamental divide in this thread.
If you mean the example of filling out a UI form, then I have to admit that I didn't really understand it. Why is any random default value suitable? Is 0 a suitable value for both the quantity you want to purchase and the street number of your address? Why not just show nil values as empty fields so you can tell which parts of the form have been filled out and which aren't? Usually I would consider the default value to be a contextual property of a given form element, not of the type that represents it.
I agree with that, but imho that doesn't make the proposed protocol useless -- and there are already small protocols in the stdlib which share some useful as well problematic aspects with this one:
Take Comparable as example.
It might be tempting to require conformance for elements of a sorted collection, but like DefaultInit, the order created by Comparable isn't the only choice, and it might be unsuited for specific use cases. Strings can be compared out of the box -- but you may want to ignore aspects like case, skip whitespace or don't follow lexicographic order at all, and rather sort strings so that the empty string is first and the one which takes up the most space last.
Even for types with only a single obvious criterion (Int, Float...), you might want to reverse the sort, so requiring Comparable conformance is inferior to the closure approach which was suggested as better alternative for DefaultInit.
But that doesn't mean Comparable is useless for a sorted collection:
It allows you to add a convenient init for elements that are Comparable so you can write
let ratings = SortedArray<Float>()
instead of
let ratings = SortedArray<Float>(orderBy: Float.<=)
That might not look like much convenience, but if I'd ever write code like
let floatFactory = Factory<Float>(initializer: Float.init)
let intFactory = Factory<Int>(initializer: Int.init)
let stringFactory = Factory<String>(initializer: String.init)
let intArrayFactory = Factory<Array<Int>>(initializer: Array.init)
I'd start thinking of a protocol like DefaultInit.