On Friday, 20 May 2016 at 12:01:14 UTC, ZombineDev wrote:
On Friday, 20 May 2016 at 11:40:12 UTC, Rene Zwanenburg wrote:
On Friday, 20 May 2016 at 11:32:16 UTC, ZombineDev wrote:
IMO, the best way forward is:
+ The compiler should lower voldemort types, according to the
scheme that Steve suggested
(http://forum.dlang.org/post/nhkmo7$ob5$1...@digitalmars.com)
+ After that, during symbol generation (mangling) if a symbol
starts getting larger than some threshold (e.g. 800
characters), the mangling algorithm should detect that and
bail out by generating some unique id instead. The only
valuable information that the symbol must include is the
module name and location (line and column number) of the
template instantiation.
Location info shouldn't be used. This will break things like
interface files and dynamic libraries.
Well... template-heavy code doesn't play well header-files and
dynamic libraries. Most of the time templates are used for the
implementation of an interface, but template types such as
ranges are unsuable in function signatures. That's why they're
called voldemort types - because they're the ones that can
not/must not be named.
Instead dynamic libraries should use stable types such as
interfaces, arrays and function pointers, which don't have the
aforementioned symbol size problems.
Since we're using random numbers for symbols (instead of the
actual names) it would not be possible for such symbols to be
part of an interface, because a different invocation of the
compiler would produce different symbol names. Such symbols
should always an implementation detail, and not part of an
interface. That's why location info would play no role, except
for debugging purposes.
@Rene
How do you expect the compiler to know the exact return type,
only by looking at this signature:
auto transmogrify(string str);
A possible implementation might be this:
auto transmogrify(string str)
{
return str.map!someFunc.filter!otherFunc.joiner();
}
or something completly different.
