My 2 cents:
I'm biased because I worked with Sean to develop this proposal, but I very
much like the idea of replacing 'type select' with 'select .type'. It
feels much more aligned with the rest of the language and removes a
special syntactic case that doesn't seem necessary to me.
We will still have open questions w.r.t. determining which field of a
union is "active", but we had those already anyway.
-Brad
On Fri, 19 Dec 2014, Sean Billig wrote:
> Proposal:
> =========
> The `type select` statement should be removed in favor of `select x.type`,
> which works today and provides nearly the same functionality.
>
>
> Rationale:
> =========
> - The `type select` statement is basically redundant. For example:
>
> var x = 5;
> type select x {
> when int do writeln("int");
> when real do writeln("real");
> }
>
> can instead be written as:
>
> var x = 5;
> select x.type {
> when int do writeln("int");
> when real do writeln("real");
> }
>
> This works in 1.10.0, and maybe in earlier releases.
>
> - Due to a bug in the current implementation of `type select`,
> there can be only one `type select` statement in a given scope.
>
>
> Caveats:
> ========
> - The behavior of the two statements isn't identical.
> `type select` uses the function resolution mechanism to choose the
> matching `when` clause, while `select` uses the equality operator (==).
> For example:
>
> var x: bool = true;
> type select x {
> when int do writeln("int");
> otherwise writeln("other");
> }
>
> This will print "int", because a variable of type `bool` can be implicitly
> converted to an `int`, following the function resolution rules.
>
> On the other hand, the `select x.type` variant:
>
> select x.type {
> when int do writeln("int");
> otherwise writeln("other");
> }
>
> will print "other", because x.type is `bool`, and `bool == int` evaluates
> to false.
>
> The `type select` behavior can be achieved using functions. For example:
>
> proc f(a: int) { writeln("int"); }
> proc f(a) { writeln("other"); }
> f(x);
>
> or via some hypothetical future type-coercion introspection abilities:
> if isImplicitlyConvertibleToInt(x) then writeln("int") else
> writeln("other");
>
> Plan:
> =====
> If there are no major objections to this proposal, `type select` will
> become a syntax error in the next release of chapel (with an error message
> suggesting `select .type`). In the following release, the parser won't
> recognize `type select`, and will generate a generic syntax error.
>
> Does anyone have any arguments against removing `type select`?
> Are there any use-cases that `type select` covers that can't
> be handled another way?
>
> Thanks,
> Sean
>
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Chapel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-users
