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.
