On Saturday, 2 September 2017 at 23:12:35 UTC, EntangledQuanta
wrote:
On Saturday, 2 September 2017 at 21:19:31 UTC, Moritz Maxeiner
wrote:
On Saturday, 2 September 2017 at 00:00:43 UTC, EntangledQuanta
wrote:
On Friday, 1 September 2017 at 23:25:04 UTC, Jesse Phillips
wrote:
I've love being able to inherit and override generic
functions in C#. Unfortunately C# doesn't use templates and
I hit so many other issues where Generics just suck.
I don't think it is appropriate to dismiss the need for the
compiler to generate a virtual function for every
instantiated T, after all, the compiler can't know you have
a finite known set of T unless you tell it.
But lets assume we've told the compiler that it is compiling
all the source code and it does not need to compile for
future linking.
First the compiler will need to make sure all virtual
functions can be generated for the derived classes. In this
case the compiler must note the template function and
validate all derived classes include it. That was easy.
Next up each instantiation of the function needs a new
v-table entry in all derived classes. Current compiler
implementation will compile each module independently of
each other; so this feature could be specified to work
within the same module or new semantics can be written up of
how the compiler modifies already compiled modules and those
which reference the compiled modules (the object sizes would
be changing due to the v-table modifications)
With those three simple changes to the language I think that
this feature will work for every T.
Specifying that there will be no further linkage is the same
as making T finite. T must be finite.
C# uses generics/IR/CLR so it can do things at run time that
is effectively compile time for D.
By simply extending the grammar slightly in an intuitive way,
we can get the explicit finite case, which is easy:
foo(T in [A,B,C])()
and possibly for your case
foo(T in <module>)() would work
or
foo(T in <program>)()
the `in` keyword makes sense here and is not used nor
ambiguous, I believe.
While I agree that `in` does make sense for the semantics
involved, it is already used to do a failable key lookup
(return pointer to value or null if not present) into an
associative array [1] and input contracts. It wouldn't be
ambiguous AFAICT, but having a keyword mean three different
things depending on context would make the language even more
complex (to read).
Yes, but they are independent, are they not? Maybe not.
foo(T in Typelist)()
in, as used here is not a input contract and completely
independent. I suppose for arrays it could be ambiguous.
The contexts being independent of each other doesn't change that
we would still be overloading the same keyword with three vastly
different meanings. Two is already bad enough imho (and if I had
a good idea with what to replace the "in" for AA's I'd propose
removing that meaning).
For me, and this is just me, I do not find it ambiguous. I
don't find different meanings ambiguous unless the context
overlaps. Perceived ambiguity is not ambiguity, it's just
ignorance... which can be overcome through learning. Hell, D
has many cases where there are perceived ambiguities... as do
most things.
It's not about ambiguity for me, it's about readability. The more
significantly different meanings you overload some keyword - or
symbol, for that matter - with, the harder it becomes to read.
But in any case, I could care less about the exact syntax. It's
just a suggestion that makes the most logical sense with regard
to the standard usage of in. If it is truly unambiguous then it
can be used.
Well, yes, as I wrote, I think it is unambiguous (and can thus be
used), I just think it shouldn't be used.
Another alternative is
foo(T of Typelist)
which, AFAIK, of is not used in D and even most programming
languages. Another could be
foo(T -> Typelist)
or even
foo(T from Typelist)
I would much rather see it as a generalization of existing
template specialization syntax [1], which this is t.b.h. just a
superset of (current syntax allows limiting to exactly one, you
propose limiting to 'n'):
---
foo(T: char) // Existing syntax: Limit T to the single type
`char`
foo(T: (A, B, C)) // New syntax: Limit T to one of A, B, or C
---
Strictly speaking, this is exactly what template specialization
is for, it's just that the current one only supports a single
type instead of a set of types.
Looking at the grammar rules, upgrading it like this is a fairly
small change, so the cost there should be minimal.
or whatever. Doesn't really matter. They all mean the same to
me once the definition has been written in stone. Could use
`foo(T eifjasldj Typelist)` for all I care.
That's okay, but it does matter to me.
The import thing for me is that such a simple syntax exists
rather than the "complex syntax's" that have already been
given(which are ultimately syntax's as everything is at the end
of the day).
Quoting a certain person (you know who you are) from DConf 2017:
"Write a DIP".
I'm quite happy to discuss this idea, but at the end of the day,
as it's not an insignificant change to the language someone will
to do the work and write a proposal.
W.r.t. to the idea in general: I think something like that
could be valuable to have in the language, but since this
essentially amounts to syntactic sugar (AFAICT), but I'm not
(yet) convinced that with `static foreach` being included it's
worth the cost.
Everything is syntactic sugar. So it isn't about if but how
much. We are all coding in 0's and 1's whether we realize it or
not. The point if syntax(or syntactic sugar) is to reduce the
amount of 0's and 1's that we have to *effectively* code by
grouping common patterns in to symbolic equivalents(by
definition).
AFAIK the difference between syntax sugar and enabling syntax in
PLs usually comes down to the former allowing you to express
concepts already representable by other constructs in the PL;
when encountered, the syntax sugar could be lowered by the
compiler to the more verbose syntax and still be both valid in
the PL and recognizable as the concept (while this is vague, a
prominent example would be lambdas in Java 8).
No one can judge the usefulness of syntax until it has been
created because what determines how useful something is is its
use. But you can't use something if it doesn't exist. I think
many fail to get that.
Why do you think that? Less than ten people have participated in
this thread so far.
The initial questions should be: Is there a gap in the
language? (Yes in this case). Can the gap be filled? (this is a
theoretical/mathematical question that has to be answered.
Most people jump the gun here and make assumptions)
Why do you assume that? I've not seen anyone here claiming
template parameter specialization to one of n types (which is the
idea I replied to) couldn't be done in theory, only that it can't
be done right now (the only claim as to that it can't be done I
noticed was w.r.t. (unspecialized) templates and virtual
functions, which is correct due to D supporting separate
compilation; specialized templates, however, should work in
theory).
Does the gap need to be filled? Yes in this case, because all
gaps ultimately need to be filled, but this then leads the
practical issues:
Actually, I disagree here. It only *needs* filling if enough
users of the language actually care about it not being there.
Otherwise, it's a *nice to have* (like generics and Go, or memory
safety and C :p ).
[1] https://dlang.org/spec/template.html#parameters_specialization
