Named arguments via struct initialization in functions

[ZombineDev via Digitalmars-d]

On Friday, 11 March 2016 at 05:09:44 UTC, Chris Wright wrote:
> 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.

It's not open-ended - size of the set is equal to the number of 
overloads taking structs, which in practice should be less than 
20.

> 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.

I'm OK with this. Even in the future we'll still need this, 
because with templates, type inference would not be possible.

>> 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.

Yes, I meant just coarse-grained AST categorization, not type 
inference. We need this to be a simple process both ease the 
implementation, as well as the human reader. Ideally, the user 
should be able to tell the difference at a glance.

>> (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.

Since DMD's parser is hand-written (and not generated from a 
grammer), I don't think it's design would be a problem. AFAIR, it 
uses arbitrary lookahead for a couple of things, because it is 
easier or faster.


> 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.

I don't think that the implementation would be a problem if we 
can convince Walter and Andrei. From what I've read in old 
bugzilla issues, they're both supportive of the idea of dedicated 
tuple syntax, however they wanted to hold from individual 
enhancements, in favour of a holistic design.