[swift-evolution] [Pitch] BitPatternRepresentable

[Karl Wagner]

> On 16. Jul 2017, at 16:26, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> on Sun Jul 16 2017, Jens Persson <swift-evolution at swift.org> wrote:
> 
>> On Wed, Jul 12, 2017 at 12:23 AM, Dave Abrahams via swift-evolution <
>> swift-evolution at swift.org> wrote:
>> 
>>> /../
>>> As ever, my first question when a new protocol is proposed is, “what
>>> generic algorithms rely on this protocol?”
>>> 
>>> 
>> First, please note that I made some mistakes in the code earlier in this
>> conversation as I did not have a compiler at hand, a better version can be
>> found in the PS-section of this post:
>> https://lists.swift.org/pipermail/swift-users/Week-of-Mon-20170710/005921.html
> 
> Looking closer at your proposal, it appears to be representing in the
> language the notion of a trivial type:
> 
> https://github.com/apple/swift/blob/2ee382efc37bc8ca2fc41495e76bd07846e6ca93/docs/ABIStabilityManifesto.md#layout-and-properties-of-types
> https://github.com/apple/swift/blob/b6ce00a012acc3f16f9d1758320fe926a92f0dd3/docs/OwnershipManifesto.md#core-definitions
> 
> That's definitely something we should do in order to support low-level
> programming.
> 
>> 
>> It contains some more context also.
>> 
>> To answer your question: I'm using it as one of the basic building blocks
>> needed for implementing generic statically allocated Vector types with
>> type-level Element and Count/Index (despite the current limitations of
>> Swift's type system!) , 
> 
> Yes, Michael Ilseman and I have solved the same problem in several ways
> ourselves.  Of course the particular problem of fixed-sized arrays
> should probably have native support, but a builtin way to identify
> trivial types at compile-time would be helpful as well.
> 
> -- 
> -Dave
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

+1 to that. @_specialized supports layout constraints. We should consider making them real generic parameter constraints in some later version of Swift, along with other loose constraints such as move-only objects, or objects with explicit value/reference semantics.

If anybody’s interested, see:

https://github.com/apple/swift/blob/ec6fc4d54db95f78ae72dab29734533f709ea2d7/include/swift/AST/KnownIdentifiers.def#L106 <https://github.com/apple/swift/blob/ec6fc4d54db95f78ae72dab29734533f709ea2d7/include/swift/AST/KnownIdentifiers.def#L106> for the list of currently-supported layout constraints, and
https://github.com/apple/swift/blob/ff6747de77597afa055bb239b3d3b215640d30ea/test/attr/attr_specialize.swift#L212 <https://github.com/apple/swift/blob/ff6747de77597afa055bb239b3d3b215640d30ea/test/attr/attr_specialize.swift#L212> for examples

- Karl

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170716/5070563c/attachment.html>