<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>I’m not sure I’m following your point here. Could you provide a simple and short code sample please?</p>

<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_1482863151004794112" 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 27. Dezember 2016 um 19:24:15, Xiaodi Wu (<a href="mailto:xiaodi.wu@gmail.com">xiaodi.wu@gmail.com</a>) schrieb:</p> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>


<title></title>


What do you think of using a value type as a subtype, and having an
initializer that supplies defaults? It can only be used once, and
after that you have to create a new value. Does that not satisfy
your compile-time needs?<br>
<div class="gmail_quote">
<div dir="ltr">On Tue, Dec 27, 2016 at 13:20 Adrian Zubarev
&lt;<a href="mailto:adrian.zubarev@devandartist.com">adrian.zubarev@devandartist.com</a>&gt;
wrote:<br></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word" class="gmail_msg">
<div class="m_8254029652668701806bloop_markdown gmail_msg">
<p class="gmail_msg">Do you have any suggestions on how this area
could be solved differently and less complex as it seems to be
here? :) I’m open minded and I’d really appreciate if we’d have
some language support for this problem.</p>
<p class="gmail_msg"></p>
</div>
<div class="m_8254029652668701806bloop_original_html gmail_msg">
</div>
</div>
<div style="word-wrap:break-word" class="gmail_msg">
<div class="m_8254029652668701806bloop_original_html gmail_msg">
<div id="m_8254029652668701806bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto" class="gmail_msg"><br class="gmail_msg"></div>
<br class="gmail_msg">
<div id="m_8254029652668701806bloop_sign_1482862693008625920" class="m_8254029652668701806bloop_sign gmail_msg">
<div style="font-family:helvetica,arial;font-size:13px" class="gmail_msg">--&nbsp;<br class="gmail_msg">
Adrian Zubarev<br class="gmail_msg">
Sent with Airmail</div>
</div>
<br class="gmail_msg"></div>
</div>
<div style="word-wrap:break-word" class="gmail_msg">
<div class="m_8254029652668701806bloop_original_html gmail_msg">
<p class="m_8254029652668701806airmail_on gmail_msg">Am 27.
Dezember 2016 um 18:49:22, Xiaodi Wu (<a href="mailto:xiaodi.wu@gmail.com" class="gmail_msg" target="_blank">xiaodi.wu@gmail.com</a>) schrieb:</p>
<blockquote type="cite" class="m_8254029652668701806clean_bq gmail_msg">
<div class="gmail_msg">
<div class="gmail_msg"></div>
<div class="gmail_msg"><span class="gmail_msg">TBH, I think you're
trying to solve this problem in a very complicated way. What you're
describing screams out for its own value subtype with let variables
and an initializer that will provide defaults. I'm skeptical such a
complicated design as you propose is necessary to achieve what you
want.<br class="gmail_msg">
<br class="gmail_msg"></span>
<div class="gmail_quote gmail_msg">
<div dir="ltr" class="gmail_msg"><span class="gmail_msg">On Tue,
Dec 27, 2016 at 05:25 Adrian Zubarev via swift-evolution
&lt;<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br class="gmail_msg"></span></div>
<blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word" class="gmail_msg">
<div class="m_8254029652668701806m_-8810590392941529495bloop_markdown gmail_msg">
<p class="gmail_msg"><span class="gmail_msg">Okay now I see your
point there. :) Thank you Xiaodi and Tony.</span></p>
<hr class="gmail_msg">
<p class="gmail_msg"><span class="gmail_msg">It’s an interesting
approach you have there, but I see another problem with
<code class="gmail_msg">Self</code> and <code class="gmail_msg">-
ProtocolName</code>. <code class="gmail_msg">Self</code> does not
refer to the current type returned from the protocol member.
SE–0068 might help there, but as soon we’re working with non-final
classes it will be problematic again.</span></p>
<p class="gmail_msg"><span class="gmail_msg">That means something
like this will be possible <code class="gmail_msg">constraint.x(1).y(1).x(2)</code>, which by solving the
main problem of this topic we’d like to avoid.</span></p>
<p class="gmail_msg"><span class="gmail_msg">We’d need a way to
subtract a protocol from the returned type + the ability of keeping
<code class="gmail_msg">T</code> only members.</span></p>
<p class="gmail_msg"><span class="gmail_msg">As for <code class="gmail_msg">T : P1 &amp; P2 &amp; P3</code>, <code class="gmail_msg">T - P1</code> should return <code class="gmail_msg">T +
P2 &amp; P3</code>, because it’s what the user would logically
assume there. The next chain needs to remember <code class="gmail_msg">- P1</code> on that path, so the result for the
followed reduction of <code class="gmail_msg">- P3</code> would be
equivalent to <code class="gmail_msg">T - P1 &amp; P3</code> =
<code class="gmail_msg">T + P2</code>.</span></p>
<p class="gmail_msg"><span class="gmail_msg">As you already
mentioned, one would assume that we might be able to cast back to
<code class="gmail_msg">T</code> from <code class="gmail_msg">T -
P1 &amp; P3</code>. I think this leads us to the right direction
where we should realize that we should escape from <code class="gmail_msg">T</code> in general. That means that the return type
should somehow create a new subtraction type, which can be reduced
further by member chaining or escaped similar to what I wrote in
the original post.</span></p>
<p class="gmail_msg"><span class="gmail_msg">We’d need a new type
or keyword that refers to the current (reduced) type. Let’s call it
<code class="gmail_msg">Current</code> instead of <code class="gmail_msg">Self</code>. Furthermore we’d need a concrete result
type, to be able to pass the result value around. Let’s call the
latter type <code class="gmail_msg">Subtraction&lt;T&gt;</code>.</span></p>
<pre class="gmail_msg"><span class="gmail_msg"><code class="m_8254029652668701806m_-8810590392941529495swift gmail_msg">protocol WidthConstrainable {
  func width(_ v: CGFloat) -&gt; Subtraction&lt;Current – WidthConstrainable&gt;
}
protocol HeightConstrainable {
  func height(_ v: CGFloat) -&gt; Subtraction&lt;Current – HeightConstrainable&gt;
}
protocol XConstrainable {
  func x(_ v: CGFloat) -&gt; Subtraction&lt;Current – XConstrainable&gt;
}
protocol YConstrainable {
  func y(_ v: CGFloat) -&gt; Subtraction&lt;Current – YConstrainable&gt;
}
struct Constraint: WidthConstrainable, HeightConstrainable, XConstrainable, YConstrainable {
  ...
}
</code></span></pre>
<p class="gmail_msg"><span class="gmail_msg"><code class="gmail_msg">Subtraction&lt;T&gt;</code> could be a similar type,
like we’re proposing to change the metatypes from <code class="gmail_msg">T.Type/Protocol</code> to <code class="gmail_msg">Type&lt;T&gt;</code> and <code class="gmail_msg">AnyType&lt;T&gt;</code>. That means that it would know
all the members of <code class="gmail_msg">Current</code> without
the subtrahend. Each further member chain would create ether a
nested <code class="gmail_msg">Subtraction&lt;Subtraction&lt;T -
P1&gt; - P2&gt;</code> or a flattened type like <code class="gmail_msg">Subtraction&lt;T - P1 &amp; P2&gt;</code>.</span></p>
<pre class="gmail_msg"><span class="gmail_msg"><code class="m_8254029652668701806m_-8810590392941529495swift gmail_msg">let constraint = Constraint()
let a: Subtraction&lt;Constraint - XConstrainable&gt; = constraint.x(1)
let b: Subtraction&lt;Subtraction&lt;Constraint - XConstrainable&gt; - YConstrainable&gt; = a.y(2)
let c: Subtraction&lt;Subtraction&lt;Subtraction&lt;Constraint - XConstrainable&gt; - YConstrainable&gt; - WidthConstrainable&gt; = b.width(100)

_ = constraint.x(1).y(2).width(100)
</code></span></pre>
<p class="gmail_msg"><span class="gmail_msg">That way we could even
remove the new <code class="gmail_msg">-</code> operator and use
generics parameter list instead. Maybe instead of <code class="gmail_msg">Subtraction</code> we could call the new type
<code class="gmail_msg">Difference&lt;T&gt;</code></span></p>
<pre class="gmail_msg"><span class="gmail_msg"><code class="m_8254029652668701806m_-8810590392941529495swift gmail_msg">type Difference&lt;Minuend, Subtrahend&gt; : Minuend - Subtrahend { … } // should know everything `Minuend` has, but exclude everything from `Subtrahend`

struct Constraint: WidthConstrainable, HeightConstrainable, XConstrainable, YConstrainable {
   func width(_ v: CGFloat) -&gt; Difference&lt;Current, WidthConstrainable&gt; {
       
      var copy = self
      copy.width = v
      return Difference(copy)
   }

   func height(_ v: CGFloat) -&gt; Difference&lt;Current,  HeightConstrainable&gt; { … }    
   func x(_ v: CGFloat) -&gt; Difference&lt;Current, XConstrainable&gt; { … }
   func y(_ v: CGFloat) -&gt; Difference&lt;Current, YConstrainable&gt; { … }
}
</code></span></pre>
<p class="gmail_msg"><span class="gmail_msg">What do you guys think
about this approach? :)</span></p>
<p class="gmail_msg"></p>
</div>
<div class="m_8254029652668701806m_-8810590392941529495bloop_original_html gmail_msg">
</div>
</div>
<div style="word-wrap:break-word" class="gmail_msg">
<div class="m_8254029652668701806m_-8810590392941529495bloop_original_html gmail_msg">
<div id="m_8254029652668701806m_-8810590392941529495bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto" class="gmail_msg"><span class="gmail_msg"><br class="gmail_msg"></span></div>
<span class="gmail_msg"><br class="gmail_msg"></span>
<div id="m_8254029652668701806m_-8810590392941529495bloop_sign_1482828564757652992" class="m_8254029652668701806m_-8810590392941529495bloop_sign gmail_msg">
<div style="font-family:helvetica,arial;font-size:13px" class="gmail_msg"><span class="gmail_msg">--&nbsp;<br class="gmail_msg">
Adrian Zubarev<br class="gmail_msg">
Sent with Airmail</span></div>
</div>
<span class="gmail_msg"><br class="gmail_msg"></span></div>
</div>
<div style="word-wrap:break-word" class="gmail_msg">
<div class="m_8254029652668701806m_-8810590392941529495bloop_original_html gmail_msg">
<p class="m_8254029652668701806m_-8810590392941529495airmail_on gmail_msg">
<span class="gmail_msg">Am 26. Dezember 2016 um 17:17:29, Tony
Allevato (<a href="mailto:allevato@google.com" class="gmail_msg" target="_blank">allevato@google.com</a>) schrieb:</span></p>
<blockquote type="cite" class="m_8254029652668701806m_-8810590392941529495clean_bq gmail_msg">
<div class="gmail_msg">
<div class="gmail_msg"></div>
<div class="gmail_msg">
<div dir="ltr" class="gmail_msg"><span class="gmail_msg"><span class="gmail_msg">Xiaodi's point is really
important—being able to express the notions simultaneously that "T
has method a()" and "T does not have method a()" would break the
type system.</span></span>
<div class="gmail_msg"><span class="gmail_msg"><br class="gmail_msg"></span></div>
<div class="gmail_msg"><span class="gmail_msg">Instead of focusing
on the proposed syntax, let's consider the problem you're trying to
solve. It sounds like what you're asking for could be expressed
more cleanly with a richer protocol algebra that supported
subtraction. It wouldn't be quite as automatic as what you propose,
but it would feel like a more natural extension of the type system
if you could do something like below, and would avoid combinatorial
explosion of protocol types (you go from O(n!) to O(n) things you
actually have to define concretely):</span></div>
<div class="gmail_msg"><span class="gmail_msg"><br class="gmail_msg"></span></div>
<div class="gmail_msg"><span class="gmail_msg">```</span></div>
<div class="gmail_msg"><span class="gmail_msg">protocol
WidthConstrainable {</span></div>
<div class="gmail_msg"><span class="gmail_msg">&nbsp; func width(_
v: CGFloat) -&gt; Self – WidthConstrainable</span></div>
<div class="gmail_msg"><span class="gmail_msg">}</span></div>
<div class="gmail_msg"><span class="gmail_msg">protocol
HeightConstrainable {</span></div>
<div class="gmail_msg"><span class="gmail_msg">&nbsp; func height(_
v: CGFloat) -&gt; Self – HeightConstrainable</span></div>
<div class="gmail_msg"><span class="gmail_msg">}</span></div>
<div class="gmail_msg"><span class="gmail_msg">protocol
XConstrainable {</span></div>
<div class="gmail_msg"><span class="gmail_msg">&nbsp; func x(_ v:
CGFloat) -&gt; Self – XConstrainable</span></div>
<div class="gmail_msg"><span class="gmail_msg">}</span></div>
<div class="gmail_msg"><span class="gmail_msg">protocol
YConstrainable {</span></div>
<div class="gmail_msg"><span class="gmail_msg">&nbsp; func y(_ v:
CGFloat) -&gt; Self – YConstrainable</span></div>
<div class="gmail_msg"><span class="gmail_msg">}</span></div>
<div class="gmail_msg"><span class="gmail_msg">struct Constraint:
WidthConstrainable, HeightConstrainable, XConstrainable,
YConstrainable {</span></div>
<div class="gmail_msg"><span class="gmail_msg">&nbsp;
...</span></div>
<div class="gmail_msg"><span class="gmail_msg">}</span></div>
<div class="gmail_msg"><span class="gmail_msg">```</span></div>
<div class="gmail_msg"><span class="gmail_msg"><br class="gmail_msg"></span></div>
<div class="gmail_msg"><span class="gmail_msg">If a type X is just
a union or protocols (for example, X: WidthConstrainable &amp;
HeightConstrainable &amp; XConstrainable &amp; YConstrainable), the
subtraction (X – something) is easy to define. It's either valid if
the subtrahend is present in the set, or it's invalid (and
detectable at compile time) if it's not.</span></div>
<div class="gmail_msg"><span class="gmail_msg"><br class="gmail_msg"></span></div>
<div class="gmail_msg"><span class="gmail_msg">But there are still
some rough edges: what does it mean when a concrete type is
involved? Let's say you have T: P1 &amp; P2 &amp; P3, and you write
(T – P1). That could give you a type that contains all the members
of T except those in P1, which would be the members in P2, P3, and
any that are defined directly on T that do not come from protocol
conformances.</span></div>
<div class="gmail_msg"><span class="gmail_msg"><br class="gmail_msg"></span></div>
<div class="gmail_msg"><span class="gmail_msg">But what is the
relationship between types T and (T – P1)? (T – P1) being a
supertype of T seems fairly straightforward—any instance of T can
be expressed as (T – P1). But if I have an instance of type (T –
P1), should I be able to cast that back to T? On the one hand, why
not? I can obviously only get (T – P1) by starting with T at some
point, so any instance of (T – P1) must *also* be an instance of T.
So that implies that T is a supertype of (T – P1). In other words,
they're supertypes of each other, without being the same type? That
would be a first in Swift's type system, I believe. And if we allow
the cast previously mentioned, that effectively circumvents the
goal you're trying to achieve. (We could argue that you'd have to
use a force-cast (as!) in this case.)</span></div>
<div class="gmail_msg"><span class="gmail_msg"><br class="gmail_msg"></span></div>
<div class="gmail_msg"><span class="gmail_msg">This could be worked
around by forbidding subtraction from concrete types and reducing T
to the union of its protocols before performing the subtraction. In
that case, (T – P1) would equal P2 &amp; P3. But that relationship
is still a little wonky: in that case, (T – P1) would also not
contain any members that are only defined on T, even though the
expression (T – P1) implies that they should. You would have to
make that reduction explicit somehow in order for that to not
surprise users (require writing something like `#protocols(of: T) –
P1`?), and it leaves a certain subset of possible type expressions
(anything that wants members defined on T without members of a
protocol) unexpressible.</span></div>
<div class="gmail_msg"><span class="gmail_msg"><br class="gmail_msg"></span></div>
<div class="gmail_msg"><span class="gmail_msg">I actually glossed
over this earlier by writing "..." in the struct body. If I defined
`width(_:)` there, what would my return type be? We currently
forbid `Self` in that context. Would `Self – WidthConstrainable` be
allowed? Would I have to use the new protocol-reduction operator
above? More details that would have to be worked out.</span></div>
<div class="gmail_msg"><span class="gmail_msg"><br class="gmail_msg"></span></div>
<div class="gmail_msg"><span class="gmail_msg">Protocol inheritance
would pose similar questions. If you have this:</span></div>
<div class="gmail_msg"><span class="gmail_msg"><br class="gmail_msg"></span></div>
<div class="gmail_msg"><span class="gmail_msg">```</span></div>
<div class="gmail_msg"><span class="gmail_msg">protocol P1
{}</span></div>
<div class="gmail_msg"><span class="gmail_msg">protocol P2: P1
{}</span></div>
<div class="gmail_msg"><span class="gmail_msg">```</span></div>
<div class="gmail_msg"><span class="gmail_msg"><br class="gmail_msg"></span></div>
<div class="gmail_msg"><span class="gmail_msg">What is the
subtype/supertype relationship between P2 and (P2 – P1)? It's the
same situation we had with a concrete type. Maybe you just can't
subtract a super-protocol without also subtracting its lowest
sub-protocol from the type?</span></div>
<div class="gmail_msg"><span class="gmail_msg"><br class="gmail_msg"></span></div>
<div class="gmail_msg"><span class="gmail_msg">My PL type theory
knowledge isn't the deepest by any means, but if something like
this was workable, I think it would be more feasible and more
expressive than the member permutation approach. And that being
said, this is probably a fairly narrow use case that wouldn't
warrant the complexity it would bring to the type system to make it
work.</span></div>
<div class="gmail_msg"><span class="gmail_msg"><br class="gmail_msg"></span></div>
</div>
<span class="gmail_msg"><br class="gmail_msg"></span>
<div class="gmail_quote gmail_msg">
<div dir="ltr" class="gmail_msg"><span class="gmail_msg">On Mon,
Dec 26, 2016 at 7:03 AM Xiaodi Wu via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br class="gmail_msg"></span></div>
<blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="gmail_msg">Should the following compile?<br class="gmail_msg">
<br class="gmail_msg">
let bar = foo.a()<br class="gmail_msg">
func f(_ g: T) {<br class="gmail_msg">
_ = g.a()<br class="gmail_msg">
}<br class="gmail_msg">
f(bar)<br class="gmail_msg">
<br class="gmail_msg">
If so, your proposal cannot guarantee each method is called only
once. If not, how can bar be of type T?<br class="gmail_msg">
<br class="gmail_msg"></span>
<div class="gmail_quote gmail_msg">
<div dir="ltr" class="gmail_msg"><span class="gmail_msg">On Mon,
Dec 26, 2016 at 06:30 Adrian Zubarev &lt;<a href="mailto:adrian.zubarev@devandartist.com" class="gmail_msg" target="_blank">adrian.zubarev@devandartist.com</a>&gt; wrote:<br class="gmail_msg"></span></div>
<blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word" class="gmail_msg">
<div class="m_8254029652668701806m_-8810590392941529495m_-3067540519206532711m_2486499801731300355bloop_markdown gmail_msg">
<p class="gmail_msg"><span class="gmail_msg">I think I revise what
I said about value semantics in my last post.</span></p>
<pre class="gmail_msg"><span class="gmail_msg"><code class="m_8254029652668701806m_-8810590392941529495m_-3067540519206532711m_2486499801731300355swift gmail_msg">let chain: T = foo.a()

let new = chain
new. // should not see `a` here
</code></span></pre>
<p class="gmail_msg"><span class="gmail_msg">It’s more something
like a local scoped chain. I’m not sure how to call it correctly
here. I’m not a native English speaker. =)</span></p>
<p class="gmail_msg"></p>
</div>
<div class="m_8254029652668701806m_-8810590392941529495m_-3067540519206532711m_2486499801731300355bloop_original_html gmail_msg">
</div>
</div>
<div style="word-wrap:break-word" class="gmail_msg">
<div class="m_8254029652668701806m_-8810590392941529495m_-3067540519206532711m_2486499801731300355bloop_original_html gmail_msg">
<div id="m_8254029652668701806m_-8810590392941529495m_-3067540519206532711m_2486499801731300355bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto" class="gmail_msg"><span class="gmail_msg"><br class="gmail_msg"></span></div>
<span class="gmail_msg"><br class="gmail_msg"></span>
<div id="m_8254029652668701806m_-8810590392941529495m_-3067540519206532711m_2486499801731300355bloop_sign_1482751593527631872" class="m_8254029652668701806m_-8810590392941529495m_-3067540519206532711m_2486499801731300355bloop_sign gmail_msg">
<div style="font-family:helvetica,arial;font-size:13px" class="gmail_msg"><span class="gmail_msg">--&nbsp;<br class="gmail_msg">
Adrian Zubarev<br class="gmail_msg">
Sent with Airmail</span></div>
</div>
<span class="gmail_msg"><br class="gmail_msg"></span></div>
</div>
<div style="word-wrap:break-word" class="gmail_msg">
<div class="m_8254029652668701806m_-8810590392941529495m_-3067540519206532711m_2486499801731300355bloop_original_html gmail_msg">
<p class="m_8254029652668701806m_-8810590392941529495m_-3067540519206532711m_2486499801731300355airmail_on gmail_msg">
<span class="gmail_msg">Am 26. Dezember 2016 um 12:11:23, Adrian
Zubarev (<a href="mailto:adrian.zubarev@devandartist.com" class="gmail_msg" target="_blank">adrian.zubarev@devandartist.com</a>)
schrieb:</span></p>
<blockquote type="cite" class="m_8254029652668701806m_-8810590392941529495m_-3067540519206532711m_2486499801731300355clean_bq gmail_msg">
<div style="word-wrap:break-word" class="gmail_msg">
<div class="gmail_msg"></div>
<div class="gmail_msg">
<div class="m_8254029652668701806m_-8810590392941529495m_-3067540519206532711m_2486499801731300355bloop_markdown gmail_msg">
<p class="gmail_msg"><span class="gmail_msg"><span class="gmail_msg">By ‘calling once’ I meant, calling once at a single
permutation chain. If the chain is escaped or followed by a
non-permuting member that returns the same protocol, you’d have the
ability to use all members at the starting point of the new
chain.</span></span></p>
<pre class="gmail_msg"><span class="gmail_msg"><code class="m_8254029652668701806m_-8810590392941529495m_-3067540519206532711m_2486499801731300355swift gmail_msg">permuting protocol T {
    func a()
    func b()
    func c()
    func d()
}

var foo: T = …

func boo(_ val: T) -&gt; U {
    // Here val escapes the chain and creates a new one
    // That means that you can create a local permutation chain here again
         
    val.a() // we can use `a` here
    return …
}

boo(foo.a()) // a is immediately invoked here
</code></span></pre>
<p class="gmail_msg"><span class="gmail_msg">I imagine this keyword
to follow value semantics, so that any possible mutation is handled
locally with a nice extra ability of permutation member
chaining.</span></p>
<p class="gmail_msg"><span class="gmail_msg">Did I understood your
point correctly here?</span></p>
<hr class="gmail_msg">
<p class="gmail_msg"><span class="gmail_msg">Sure the idea needs to
be more fleshed out, but I’m curious if that’s something that we
might see in Swift one day. :)</span></p>
</div>
<div class="m_8254029652668701806m_-8810590392941529495m_-3067540519206532711m_2486499801731300355bloop_original_html gmail_msg">
<div id="m_8254029652668701806m_-8810590392941529495m_-3067540519206532711m_2486499801731300355bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto" class="gmail_msg"><span class="gmail_msg"><br class="gmail_msg"></span></div>
<span class="gmail_msg"><br class="gmail_msg"></span>
<div id="m_8254029652668701806m_-8810590392941529495m_-3067540519206532711m_2486499801731300355bloop_sign_1482749838336907008" class="m_8254029652668701806m_-8810590392941529495m_-3067540519206532711m_2486499801731300355bloop_sign gmail_msg">
<div style="font-family:helvetica,arial;font-size:13px" class="gmail_msg"><span class="gmail_msg">--&nbsp;<br class="gmail_msg">
Adrian Zubarev<br class="gmail_msg">
Sent with Airmail</span></div>
</div>
<span class="gmail_msg"><br class="gmail_msg"></span>
<p class="m_8254029652668701806m_-8810590392941529495m_-3067540519206532711m_2486499801731300355airmail_on gmail_msg">
<span class="gmail_msg">Am 26. Dezember 2016 um 11:50:50, Xiaodi Wu
(<a href="mailto:xiaodi.wu@gmail.com" class="gmail_msg" target="_blank">xiaodi.wu@gmail.com</a>) schrieb:</span></p>
<blockquote type="cite" class="m_8254029652668701806m_-8810590392941529495m_-3067540519206532711m_2486499801731300355clean_bq gmail_msg">
<div class="gmail_msg"><span class="gmail_msg"><span class="gmail_msg"><span style="color:rgb(0,0,0);font-family:'helvetica Neue',helvetica;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);display:inline!important;float:none" class="gmail_msg">Given `foo: T` and methods a(), b(), c(), d(),
each of which can only be called once, how can the return value of
these methods be represented in the type system?</span><br style="color:rgb(0,0,0);font-family:'helvetica Neue',helvetica;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="gmail_msg">
<br style="color:rgb(0,0,0);font-family:'helvetica Neue',helvetica;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="gmail_msg">
<span style="color:rgb(0,0,0);font-family:'helvetica Neue',helvetica;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);display:inline!important;float:none" class="gmail_msg">That is, if `foo.a()` can be passed as an
argument to an arbitrary function of type `(T) -&gt; U`, either the
function cannot immediately invoke a(), in which case foo is not of
type T, or it can immediately invoke a(), in which case your
keyword does not work.</span></span></span></div>
</blockquote>
</div>
<div class="m_8254029652668701806m_-8810590392941529495m_-3067540519206532711m_2486499801731300355bloop_markdown gmail_msg">
</div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>


</div></div></span></blockquote></div><div class="bloop_markdown"><p></p></div></body></html>