This should throw a compile-time error about ambiguous type promotion. One could argue that real(32) is sufficient and therefore "closer" but that might lead to situations where suboptimal code is generated because a function that returns real(32) is fed into a function that needs real(64). In that case, promoting int into real(64) would not require a subsequent cast from real(32) to real(64) later. Forcing the programmer to be explicit requires more work up front but mitigates a variety of nasty surprises later.
I can't remember what C++ does with this sort of thing, but I recall that it does something frustrating with uint32_t vs int64_t or something along those lines (StackOverflow is likely a source of examples that confound users...). Best, Jeff On Wed, May 27, 2015 at 5:11 PM, Brad Chamberlain <[email protected]> wrote: > > Hi Chapel Users -- > > We wanted to highlight a question that came up recently on a sibling > thread in hopes of getting feedback from the community. Perhaps most > simply, given the following code: > > var i: int(32) = 42; > > foo(i); // call requires coercion from int to real > > proc foo(x: real(32)) { writeln("In 32-bit version"); } > > proc foo(x: real(64)) { writeln("In 64-bit version"); } > > Which of the two calls would you want/expect foo() to dispatch to (if > either one)? > > > While this example is fairly arbitrary, note that this has implications > for things like which math operators are invoked in cases where there is > no precisely matching signature for the two argument types, such as: > > ...i * 2.5... > > > We'd appreciate hearing any heartfelt opinions on this topic. Opinions > with supporting rationale are particularly appreciated. > > Thanks, > -Brad > > > ------------------------------------------------------------------------------ > _______________________________________________ > Chapel-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/chapel-users -- Jeff Hammond [email protected] http://jeffhammond.github.io/ ------------------------------------------------------------------------------ _______________________________________________ Chapel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-users
