<html><head><style>
body {
        font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;
        padding:1em;
        margin:auto;
        background:#fefefe;
}

h1, h2, h3, h4, h5, h6 {
        font-weight: bold;
}

h1 {
        color: #000000;
        font-size: 28pt;
}

h2 {
        border-bottom: 1px solid #CCCCCC;
        color: #000000;
        font-size: 24px;
}

h3 {
        font-size: 18px;
}

h4 {
        font-size: 16px;
}

h5 {
        font-size: 14px;
}

h6 {
        color: #777777;
        background-color: inherit;
        font-size: 14px;
}

hr {
        height: 0.2em;
        border: 0;
        color: #CCCCCC;
        background-color: #CCCCCC;
    display: inherit;
}

p, blockquote, ul, ol, dl, li, table, pre {
        margin: 15px 0;
}

a, a:visited {
        color: #4183C4;
        background-color: inherit;
        text-decoration: none;
}

#message {
        border-radius: 6px;
        border: 1px solid #ccc;
        display:block;
        width:100%;
        height:60px;
        margin:6px 0px;
}

button, #ws {
        font-size: 12 pt;
        padding: 4px 6px;
        border-radius: 5px;
        border: 1px solid #bbb;
        background-color: #eee;
}

code, pre, #ws, #message {
        font-family: Monaco;
        font-size: 10pt;
        border-radius: 3px;
        background-color: #F8F8F8;
        color: inherit;
}

code {
        border: 1px solid #EAEAEA;
        margin: 0 2px;
        padding: 0 5px;
}

pre {
        border: 1px solid #CCCCCC;
        overflow: auto;
        padding: 4px 8px;
}

pre > code {
        border: 0;
        margin: 0;
        padding: 0;
}

#ws { background-color: #f8f8f8; }


.bloop_markdown table {
border-collapse: collapse;  
font-family: Helvetica, arial, freesans, clean, sans-serif;  
color: rgb(51, 51, 51);  
font-size: 15px; line-height: 25px;
padding: 0; }

.bloop_markdown table tr {
border-top: 1px solid #cccccc;
background-color: white;
margin: 0;
padding: 0; }
     
.bloop_markdown table tr:nth-child(2n) {
background-color: #f8f8f8; }

.bloop_markdown table tr th {
font-weight: bold;
border: 1px solid #cccccc;
margin: 0;
padding: 6px 13px; }

.bloop_markdown table tr td {
border: 1px solid #cccccc;
margin: 0;
padding: 6px 13px; }

.bloop_markdown table tr th :first-child, table tr td :first-child {
margin-top: 0; }

.bloop_markdown table tr th :last-child, table tr td :last-child {
margin-bottom: 0; }

.bloop_markdown blockquote{
  border-left: 4px solid #dddddd;
  padding: 0 15px;
  color: #777777; }
  blockquote > :first-child {
    margin-top: 0; }
  blockquote > :last-child {
    margin-bottom: 0; }

code, pre, #ws, #message {
    word-break: normal;
    word-wrap: normal;
}

hr {
    display: inherit;
}

.bloop_markdown :first-child {
    -webkit-margin-before: 0;
}

code, pre, #ws, #message {
    font-family: Menlo, Consolas, Liberation Mono, Courier, monospace;
}


.send { color:#77bb77; }
.server { color:#7799bb; }
.error { color:#AA0000; }</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="bloop_markdown"><p>Honestly I read your post twice and I still having issues to understand what exactly you’re proposing.</p>

<p>Now about <code>final</code> on protocols. IMO this is a bad choice, because I would think that you cannot conform to that protocol, not could you refine it with another protocol, because it’s <code>final</code> after all.</p>

<p>The whole post seemed to me like an *existential of structs* with a special interface, am I wrong here?</p>

<p>I myself would want to see more constraints for protocols like this:</p>

<pre><code class="swift">protocol P1 : AnyStruct { … } // for structs only
protocol P2 : AnyEnum { … }   // for enums only
protocol P3 : AnyValue { … }  // for any extensible value type

protocol p4 : ValueSemantics { … } // Force value semantics (can be a class if not constrained otherwise)

// Soon we'll have this (SE-0156: https://github.com/apple/swift-evolution/blob/master/proposals/0156-subclass-existentials.md)
protocol P5 : AnyObject { … }

// instead of
protocol P5 : class { … }
</code></pre>

<p></p></div><div class="bloop_original_html"><style>body{font-family:Helvetica,Arial;font-size:13px}</style><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div> <br> <div id="bloop_sign_1492078980169077760" class="bloop_sign"><div style="font-family:helvetica,arial;font-size:13px">--&nbsp;<br>Adrian Zubarev<br>Sent with Airmail</div></div> <br><p class="airmail_on">Am 13. April 2017 um 11:25:49, Andrey Volodin via swift-evolution (<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>) schrieb:</p> <blockquote type="cite" class="clean_bq"><span><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div></div><div>


<title></title>


Hello everyone!
<div class=""><br class=""></div>
<div class="">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).</div>
<div class=""><br class=""></div>
<div class="">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.&nbsp;</div>
<div class=""><br class=""></div>
<div class=""><b class="">Problem:&nbsp;</b></div>
<div class="">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.&nbsp;</div>
<div class=""><br class=""></div>
<div class=""><b class="">Proposal:</b></div>
<div class="">Wouldn’t it be nice if we could invent a way to
globalize types like that?&nbsp;</div>
<div class=""><br class=""></div>
<div class="">Imagine you declare something like this in your
imaginary triangulation library:</div>
<div class=""><br class=""></div>
<div class="">
<div style="margin: 0px; line-height: normal; font-family: Menlo;" class=""><b class=""><span style="font-variant-ligatures: no-common-ligatures;" class="">final</span><span style="font-variant-ligatures: no-common-ligatures;" class="">&nbsp;public&nbsp;</span><span style="font-variant-ligatures: no-common-ligatures;" class="">protocol</span> <span style="font-variant-ligatures: no-common-ligatures;" class="">Vector2D {
// or the syntax could be `Vector2D: struct`</span></b></div>
<div style="margin: 0px; line-height: normal; font-family: Menlo;" class=""><b class=""><span style="font-variant-ligatures: no-common-ligatures" class="">&nbsp;
&nbsp;</span> <span style="font-variant-ligatures: no-common-ligatures;" class="">var</span>
<span style="font-variant-ligatures: no-common-ligatures" class="">x:</span> <span style="font-variant-ligatures: no-common-ligatures;" class="">Double</span> <span style="font-variant-ligatures: no-common-ligatures" class="">{</span>
<span style="font-variant-ligatures: no-common-ligatures;" class="">get</span> <span style="font-variant-ligatures: no-common-ligatures;" class="">set</span>
<span style="font-variant-ligatures: no-common-ligatures" class="">}</span></b></div>
<div style="margin: 0px; line-height: normal; font-family: Menlo;" class=""><b class=""><span style="font-variant-ligatures: no-common-ligatures" class="">&nbsp;
&nbsp;</span> <span style="font-variant-ligatures: no-common-ligatures;" class="">var</span>
<span style="font-variant-ligatures: no-common-ligatures" class="">y:</span> <span style="font-variant-ligatures: no-common-ligatures;" class="">Double</span> <span style="font-variant-ligatures: no-common-ligatures" class="">{</span>
<span style="font-variant-ligatures: no-common-ligatures;" class="">get</span> <span style="font-variant-ligatures: no-common-ligatures;" class="">set</span>
<span style="font-variant-ligatures: no-common-ligatures" class="">}</span></b></div>
<div style="margin: 0px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""><b class="">}</b></span></div>
</div>
<div class=""><br class=""></div>
<div class="">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:</div>
<div class=""><br class=""></div>
<div class="">
<div style="margin: 0px; line-height: normal; font-family: Menlo;" class=""><b class=""><span style="font-variant-ligatures: no-common-ligatures;" class="">public</span> <span style="font-variant-ligatures: no-common-ligatures;" class="">extension</span> <span style="font-variant-ligatures: no-common-ligatures;" class="">Point2D</span><span style="font-variant-ligatures: no-common-ligatures;" class="">:</span>
<span style="font-variant-ligatures: no-common-ligatures;" class="">Vector2D</span> <span style="font-variant-ligatures: no-common-ligatures;" class="">{}</span></b></div>
</div>
<div style="margin: 0px; line-height: normal; font-family: Menlo;" class=""><br class=""></div>
<div style="margin: 0px; line-height: normal;" class="">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.</div>
<div style="margin: 0px; line-height: normal;" class=""><br class=""></div>
<div style="margin: 0px; line-height: normal;" class="">For example
we have a bunch of C libs like <b class="">OpenCV</b> or <b class="">dlib</b> 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.&nbsp;</div>
<div style="margin: 0px; line-height: normal;" class=""><br class=""></div>
<div style="margin: 0px; line-height: normal;" class="">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.</div>
<div style="margin: 0px; line-height: normal;" class=""><br class=""></div>
<div style="margin: 0px; line-height: normal;" class="">Once again:
I know this is kind of arguable thing, I just wanted to know your
opinion on that.</div>
<div style="margin: 0px; line-height: normal;" class=""><br class=""></div>
<div style="margin: 0px; line-height: normal;" class="">Thanks for
your attention,</div>
<div style="margin: 0px; line-height: normal;" class="">Andrey
Volodin</div>


_______________________________________________<br>swift-evolution mailing list<br>swift-evolution@swift.org<br>https://lists.swift.org/mailman/listinfo/swift-evolution<br></div></div></span></blockquote></div><div class="bloop_markdown"><p></p></div></body></html>