<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br></div><div><br>On Jun 15, 2016, at 8:24 AM, Adrian Zubarev via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><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><div class="bloop_markdown"><p>I guess you don’t understand that a so called <strong>proposal</strong> should have enough details to explain the proposed behavior to someone who is not the author of the proposal. You’re offering is fine but a few unexplained lines of your gist wouldn’t make through a proposal review at all.</p></div></div></blockquote><div>I'm sure you have no doubt understood that it is NOT a formal proposal yet, but more a attempt at showing that the current ones are far more complicated than they ought to be.</div><br><blockquote type="cite"><div><div class="bloop_markdown"><p>I rather give a book to someone to read then a few unexplained samples where you’d scratch your head trying to figure out what my intention <em>might</em> mean. I’m sure you learned math theories not by looking at complex formulas without reading any explanation about what its parameter and mathematical-syntax mean, if you ever did. I’m not trying to insult here anyone so don’t take that to personal!</p></div></div></blockquote><div>May I remind you that we are talking about language design, which basically means we are talking about grammar design. Which means that a good solution would start with a good grammar, with enough examples that it might even be enough to fully and unambiguously describe everything. Words are of course always welcome to highlight the fine prints.</div><div><br></div><div>The proposals I have seen are unclear, not because i say so, but because they need a loooot of explaining to try to explain things. Look at ANY programming language... even haskell's existentials can be clearly and simply explained.</div><div><br></div><div>Someone said: "that which is conceived well we can describe clearly and the words to say it come easily"</div><br><blockquote type="cite"><div><div class="bloop_markdown">
<p>That said, I’m strongly against that ugly and not swifty looking <code>_[ ]</code> syntax. <code>ClassName[Params]</code> is okay but an empty <code>_[ ]</code> is just ugly. Again this is my personal opinion and it’s up to the core team to decide.</p></div></div></blockquote><div>I am sure you realized that nobody except the compiler care about _[] as it is just the degenerate case showing that the grammar needs no magic.</div><div> </div><div>Typealias WhatEverItMayBe = _[] </div><div>Is the only thing anyone would ever care about... Which means, as i wrote in the gist, that it can even be <b>Any</b></div><div><br></div><br><blockquote type="cite"><div><div class="bloop_markdown">
<p>If we’d look at your so called ‘absurd’ example and imagine the shorthand syntax support class-requirements like proposed:</p>
<p><code>let v: UIViewController & UIWindow & UITableViewDelegate</code></p>
<p>there is definitely one thing that should happen for sure:</p>
<ul>
<li>complier should raise an error at compile time right after typing out the whole existential type or even after <code>UIViewController & UIWindow</code>.</li>
<li>such an error message would provide enough informations for you that an existential type with class requirements cannot be composed with two classes (without nesting existentials)</li></ul></div></div></blockquote><div><br></div><div>I'm sorry, i fail to see which grammar this example is following. Not the one i was exploring right? Because my point is precisely to NOT have this kind of syntax that work in emails but only with lots of "and this would happen, and that would be done". IMVHE they turn into inelegant code, and cumbersome to generate error messages. A compiler is a mechanical tool for processing GRAMMARS. If a grammar is good, many problems don't even parse completely, relieving the type checker from dealing with them.</div><br><blockquote type="cite"><div><div class="bloop_markdown"><ul>
</ul>
<p>Lets try nesting:</p>
<p><code>let v: UIViewController & (UIWindow & UITableViewDelegate)</code></p>
<p>this will again raise an error and tell you that <code>UIViewController</code> and <code>UIWindow</code> has no subtyping-relationship and are incompatible class types.</p>
<p>If you tried creating an existential type without reading and learning from docs first, lets say it’s your own fault that you will end up with these error messages, but either way you’d quickly learn how they behave.</p></div></div></blockquote><div>Disagree... a well designed <b>regular</b> grammar makes a language feel self evident... a bad one makes you question what's going on even as you progress... trust me (or better, don't), i learned enough languages in my professional life to have noticed that.</div><br><blockquote type="cite"><div><div class="bloop_markdown">
<p>That said, merging types to existentials </p></div></div></blockquote><div>Do u mean protocol? The existential type is the result.</div><div><br></div><blockquote type="cite"><div><div class="bloop_markdown"><p>with an infix <code>&</code> operator does look swifty to me (my opinion again) and is intuitive enough for that behavior. </p>
<p>You may ask for <code>|</code> operator, but this is a different story here. I’d support it to be able reduce overloading:</p></div></div></blockquote><blockquote type="cite"><div><div class="bloop_markdown">
<pre><code class="swift">func foo(value: OneOf<A, B, C>) { … }
func foo(value: A | B | C) { … }
// Imagine AnyStruct and AnyEnum (they probably won't make it into Swift)
typealias AnyValue = AnyStruct | AnyEnum
</code></pre></div></div></blockquote><div><br></div><div>They mean nothing useful, why would one go through the trouble of creating them?</div><div><br></div><blockquote type="cite"><div><div class="bloop_markdown"><pre><code class="swift">// almost `Any`, we miss tuples and closures/functions here
typealias AnyExtendible = AnyValue | AnyObject
</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_1465969389854994176" class="bloop_sign"><div style="font-family:helvetica,arial;font-size:13px">-- <br>Adrian Zubarev<br>Sent with Airmail</div></div> <br><p class="airmail_on">Am 15. Juni 2016 um 06:27:19, L. Mihalkovic (<a href="mailto:laurent.mihalkovic@gmail.com">laurent.mihalkovic@gmail.com</a>) schrieb:</p> <blockquote type="cite" class="clean_bq"><span><div dir="auto"><div></div><div>
<title></title>
<div>You need 3 long paragraph to explain it, the alternative I
offer requires none.</div>
<div id="AppleMailSignature"><br></div>
<div id="AppleMailSignature"><a href="https://gist.github.com/lmihalkovic/68c321ea7ffe27e553e37b794309b051">
https://gist.github.com/lmihalkovic/68c321ea7ffe27e553e37b794309b051</a><br>
<br>
<div>Regards</div>
(From<span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.294118);"> mobile)</span></div>
<div><br>
On Jun 14, 2016, at 11:44 PM, Adrian Zubarev via swift-evolution
<<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>
wrote:<br>
<br></div>
<blockquote type="cite">
<div>
<div class="bloop_markdown">
<p>One more thing for clarity:</p>
<ul>
<li>
<p><strong>Any-class requirement:</strong> This must be the first
requirement, if present. This requirement consists of the keyword
<code>class</code>, and requires the existential to be of any class
type.</p>
</li>
<li>
<p><strong>Class requirement:</strong> <u>This must be the first
requirement, if present. This requirement consists of the
<code>name</code> of a class type, and requires the existential to
be of a specific class or its subclasses. <strong>There can be only
one class name constraint</strong>, and it is mutually exclusive
with the any-class requirement.</u></p>
</li>
<li>
<p><strong>Nested <code>any<...></code>:</strong> This
requirement consists of another <code>any<...></code>
construct.</p>
</li>
</ul>
</div>
<div class="bloop_original_html">
<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_1465940594688024064" class="bloop_sign">
<div style="font-family:helvetica,arial;font-size:13px">
-- <br>
Adrian Zubarev<br>
Sent with Airmail</div>
</div>
<br>
<p class="airmail_on">Am 14. Juni 2016 um 23:42:00, Adrian Zubarev
(<a href="mailto:adrian.zubarev@devandartist.com">adrian.zubarev@devandartist.com</a>)
schrieb:</p>
<blockquote type="cite" class="clean_bq">
<div>
<div 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; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">
<span>Which addresses the fact that nons of the proposals so far
truly prevent absurde declarations like:</span></div>
<div 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; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">
<span><br></span></div>
<div 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; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">
<span>Let v: Any< UIViewController, UIWindow,
UITableViewDelegate></span></div>
<div 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; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">
<span>Let v:<span class="Apple-converted-space"> </span><span style="background-color: rgba(255, 255, 255, 0);">UIViewController &
UIWindow & UITableViewDelegate</span></span></div>
</div>
</blockquote>
</div>
<div class="bloop_markdown"></div>
</div>
</blockquote>
<blockquote type="cite">
<div>
<span>_______________________________________________</span><br>
<span>swift-evolution mailing list</span><br>
<span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br>
<span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br>
</div>
</blockquote>
</div></div></span></blockquote></div><div class="bloop_markdown"><p></p></div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>