Named arguments via struct initialization in functions

[Chris Wright via Digitalmars-d]

On Thu, 10 Mar 2016 19:01:53 +0000, ZombineDev wrote:

> On Monday, 7 March 2016 at 19:06:54 UTC, Chris Wright wrote:
>> On Mon, 07 Mar 2016 11:06:13 +0000, ZombineDev wrote:
>>> The compiler should detect that this call is ambiguous and would not
>>> allow it.
>>
>> It's a potentially significant amount of work to determine that the
>> expression is ambiguous, or to disambiguate.
> 
> I don't think so. At least not much more than what currently the
> compiler does for overload resolution (comparing the void(A) overloard
> to the void(B)).

Currently, overload resolution deals with a similar problem with numeric 
literals. But there's a big difference between supporting it for one 
class of related types that's all known at compile time, and supporting 
it for an open-ended set of types that are entirely unrelated.

If I were implement this, the first pass would require struct literal 
expressions to include the struct type. I might later consider whether to 
change that.

> Tuples literals / struct initializer literals /
> delegates should be classified before the end of the parsing phase

That is, you can determine whether something is a delegate literal or a 
struct literal (even without marking struct literals with their type) 
during parsing. For a moment, I misunderstood and thought you were 
talking about assigning types to them.

> (which is actually at least an order of magnitude faster than the
> semantic phase).

It wouldn't be parseable with an LL(k) parser, which is a minor thing. 
More to the point, depending on how DMD's parser is designed, it might be 
pretty awkward to parse something that might be a labeled statement or a 
struct variable initializer.

If we can get something that's approximately as good (arguably better 
because it's less ambiguous, arguably worse because it's more to type) 
with far less work, then, given the small number of people who contribute 
to DMD, it would behoove us to choose the easier option.