[swift-evolution] [Pitch] Add the DefaultConstructible protocol to the standard library
Chris Lattner
clattner at apple.com
Wed Dec 28 22:00:09 CST 2016
> On Dec 28, 2016, at 2:24 PM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> wrote:
>
> On Wed, Dec 28, 2016 at 5:21 PM, Anton Zhilin <antonyzhilin at gmail.com <mailto:antonyzhilin at gmail.com>> wrote:
> What about “Rust way”?
>
> protocol Default {
> static var `default`: Self { get }
> }
>
> protocol Setupable {
> mutable func setup(with params: Params)
> }
>
> func setupArray<T>(type: T.Type, params: Params) -> [T]
> where T: Default & Setupable
> {
> return (1...42).map { i in
> var next = T.default
> next.setup(with: params)
> return next
> }
> }
> default is literally a “default” value. For primitives like Int, Char, Bool, Float etc. it is all zeros. For structs with Default fields, it’s all defaults—unless some special semantics is given to them. For complex types, it’s an “empty” value, the most sane value before any setup or specification.
>
>
> The objection is not about the spelling. The point here is that such a protocol does not make sufficient semantic guarantees to enable any interesting generic algorithms not possible without it. As I pointed out, Rust explicitly makes no guarantees as to what the default value is and tells you that you must not care; "most sane" does not cut it as a guarantee.
Right.
Anton, perhaps I missed it, but I haven’t seen any concrete rationale for your proposal. Can you give some specific code examples that become simpler with a default constructible protocol? Perhaps you’re getting pushback because there is a better way to solve the problem you’re facing.
-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161228/43b970a5/attachment.html>
More information about the swift-evolution
mailing list