<div dir="ltr">I&#39;ve been thinking about naming a bit. I&#39;m worried that &quot;values&quot; / &quot;allValues&quot; won&#39;t make sense if this feature eventually goes in the direction of returning type constructors. For enums with associated types, the cases may actually be <b>functions</b> taking the associated type and returning the enum type. (There&#39;s an example under &quot;Future directions&quot; in the proposal). Calling these &quot;values&quot; seems strange to me, but calling them &quot;cases&quot; makes sense.<div><div><br></div><div>Even though the &quot;case&quot; <i>keyword</i> is mostly used with enums, I think the actual English <i>word</i> &quot;case&quot; applies pretty well when thinking about any type, not just enums. It refers to a member of the type. T.cases or T.allCases are all the cases of valid instances/members of the type.</div><div><br></div><div>&quot;FiniteType&quot; is technically accurate, but to me it doesn&#39;t evoke &quot;this protocol allows you to enumerate the type&#39;s values&quot;. I&#39;m leaning toward the names that end in -Enumerable.</div><div><br></div><div>Unless someone has a compelling argument otherwise, I may leave the naming as-is in the proposal, and let the core team bikeshed it to their liking :)<br><div class="gmail_extra">
<br><div class="gmail_quote">On Wed, Jan 20, 2016 at 8:45 AM, Denis Nikitenko <span dir="ltr">&lt;<a href="mailto:d.nikitenko@icloud.com" target="_blank">d.nikitenko@icloud.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">For the protocol name, I rather like FiniteType (or FiniteValueType), since I find it to be more general and future-proof.  ValueEnumerable would also work, though.<br>
<br>
My preference for the static var would be T.values or T.allValues - we want to get all values of the finite type T.<br>
<br>
Definitely a +1 on the overall proposal.<br>
<span><br>
<br>
<br>
&gt;&gt; On Jan 18, 2016, at 11:15 PM, Jacob Bandes-Storch via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; OK, I can see the argument here. I was worried about making this proposal so broad that it wouldn&#39;t be seriously considered, but I agree that choosing more general names will open it up to future expansion.<br>
&gt;&gt;<br>
&gt;&gt; Here are some more name ideas:<br>
&gt;&gt;<br>
&gt;&gt; - CaseEnumerable (in the proposal draft)<br>
&gt;&gt; - T.cases (in the proposal draft)<br>
&gt;&gt; - T.allCases<br>
&gt;&gt; - FiniteType (as you suggested)<br>
&gt;&gt; - FiniteValueType<br>
&gt;&gt; - ValueEnumerable<br>
&gt;&gt; - T.values<br>
&gt;&gt; - T.allValues<br>
&gt;&gt;<br>
&gt;&gt; Thoughts? More suggestions? I think I like ValueEnumerable.<br>
&gt;&gt;<br>
&gt;<br>
</span><div><div>&gt; _______________________________________________<br>
&gt; swift-evolution mailing list<br>
&gt; <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
&gt; <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
</div></div></blockquote></div><br></div></div></div></div>