Hi,
While working on a D project which heavily uses the lazy
algorithms for ranges I noticed a sudden huge increase in the
compilation time and the produced binary size.
I chased down the offending change to just a small change in one
line of the code which made the resulting binary to jump
On 05/17/2016 05:44 PM, Georgi D wrote:
Hi,
While working on a D project which heavily uses the lazy algorithms for
ranges I noticed a sudden huge increase in the compilation time and the
produced binary size.
[snip]
Thanks. That's definitely deserving of a bug report. -- Andrei
On Tuesday, 17 May 2016 at 21:58:06 UTC, Andrei Alexandrescu
wrote:
On 05/17/2016 05:44 PM, Georgi D wrote:
Hi,
While working on a D project which heavily uses the lazy
algorithms for
ranges I noticed a sudden huge increase in the compilation
time and the
produced binary size.
[snip]
Thank
On Tuesday, 17 May 2016 at 21:58:06 UTC, Andrei Alexandrescu
wrote:
On 05/17/2016 05:44 PM, Georgi D wrote:
Hi,
While working on a D project which heavily uses the lazy
algorithms for
ranges I noticed a sudden huge increase in the compilation
time and the
produced binary size.
[snip]
Thank
On 5/17/16 6:04 PM, ZombineDev wrote:
On Tuesday, 17 May 2016 at 21:58:06 UTC, Andrei Alexandrescu wrote:
On 05/17/2016 05:44 PM, Georgi D wrote:
Hi,
While working on a D project which heavily uses the lazy algorithms for
ranges I noticed a sudden huge increase in the compilation time and the
On 05/19/2016 08:38 AM, Steven Schveighoffer wrote:
Yep. chain uses voldemort type, map does not.
We definitely need to fix Voldemort types. Walter and I bounced a few
ideas during DConf.
1. Do the cleartext/compress/hash troika everywhere (currently we do it
on Windows). That should help i
On 5/19/16 9:45 AM, Andrei Alexandrescu wrote:
On 05/19/2016 08:38 AM, Steven Schveighoffer wrote:
Yep. chain uses voldemort type, map does not.
We definitely need to fix Voldemort types. Walter and I bounced a few
ideas during DConf.
1. Do the cleartext/compress/hash troika everywhere (curre
On 05/19/2016 10:43 AM, Steven Schveighoffer wrote:
This may be crazy, but I solved this problem by simply moving the struct
outside the function. What about a lowering that does this for you?
That's also a possibility, but likely a more complicated one. -- Andrei
On 20/05/2016 12:44 AM, Andrei Alexandrescu wrote:
On 05/19/2016 10:43 AM, Steven Schveighoffer wrote:
This may be crazy, but I solved this problem by simply moving the struct
outside the function. What about a lowering that does this for you?
That's also a possibility, but likely a more compl
On 5/19/16 10:56 AM, Daniel Murphy wrote:
On 20/05/2016 12:44 AM, Andrei Alexandrescu wrote:
On 05/19/2016 10:43 AM, Steven Schveighoffer wrote:
This may be crazy, but I solved this problem by simply moving the struct
outside the function. What about a lowering that does this for you?
That's
On 5/19/16 10:43 AM, Steven Schveighoffer wrote:
Or even better:
template(T) foo if (someConstraints)
{
struct Result
{
T t;
}
auto foo(T t)
{
return Result(t);
}
}
This solution works awesomely, actually. It even produces smaller code
than moving the s
On Thursday, 19 May 2016 at 12:38:09 UTC, Steven Schveighoffer
wrote:
On 5/17/16 6:04 PM, ZombineDev wrote:
On Tuesday, 17 May 2016 at 21:58:06 UTC, Andrei Alexandrescu
wrote:
On 05/17/2016 05:44 PM, Georgi D wrote:
Hi,
While working on a D project which heavily uses the lazy
algorithms for
On 5/19/16 11:56 AM, Georgi D wrote:
On Thursday, 19 May 2016 at 12:38:09 UTC, Steven Schveighoffer wrote:
On 5/17/16 6:04 PM, ZombineDev wrote:
I'm guessing that is highly related to this one:
https://issues.dlang.org/show_bug.cgi?id=15831
Yep. chain uses voldemort type, map does not.
Georg
On 05/19/2016 11:56 AM, Georgi D wrote:
Making a local copy of chain and moving the structure outside of the
method solved the problem and reduced the code size.
The stripped size even reduced from the version that did not experience
the huge increase. Stripped: 7.4Mb -> 5.5MB
Thanks very much
On 5/19/2016 8:39 AM, Steven Schveighoffer wrote:
template(T) foo if (someConstraints)
{
struct Result
{
T t;
}
auto foo(T t)
{
return Result(t);
}
}
This solution works awesomely, actually. It even produces smaller code than
moving the struct completely o
On 5/19/2016 6:45 AM, Andrei Alexandrescu wrote:
I very much advocate slapping a 64-long random string for all Voldermort returns
and calling it a day. I bet Liran's code will get a lot quicker to build and
smaller to boot.
Let's see how far we get with compression first.
https://github.com/
On Thursday, 19 May 2016 at 22:16:03 UTC, Walter Bright wrote:
Using 64 character random strings will make symbolic debugging
unpleasant.
Using 6.4 megabyte strings already makes symbolic debugging
unpleasant.
The one thing that worries me about random strings is that it
needs to be the sam
On Thursday, 19 May 2016 at 22:17:37 UTC, Walter Bright wrote:
Consider using a 'static struct'. A non-static struct will
include a hidden member that points to the stack frame of
foo(), i.e. "produces smaller code".
Queue me going to the language reference to look up static
structs and rea
On 5/19/2016 4:36 PM, jmh530 wrote:
Queue me going to the language reference to look up static structs and reading
"A struct can be prevented from being nested by using the static attribute, but
then of course it will not be able to access variables from its enclosing
scope."
Not a fan of that
On Thursday, 19 May 2016 at 22:46:02 UTC, Adam D. Ruppe wrote:
On Thursday, 19 May 2016 at 22:16:03 UTC, Walter Bright wrote:
Using 64 character random strings will make symbolic debugging
unpleasant.
Using 6.4 megabyte strings already makes symbolic debugging
unpleasant.
The one thing that
On Thursday, 19 May 2016 at 23:56:46 UTC, poliklosio wrote:
(...)
Clearly the reason for building such a gigantic string was some
sort of repetition. Detect the repetition on-the-fly to avoid
processing all of it. This way the generated name is already
compressed.
It seems like dynamic progr
On Thursday, 19 May 2016 at 22:46:02 UTC, Adam D. Ruppe wrote:
On Thursday, 19 May 2016 at 22:16:03 UTC, Walter Bright wrote:
Using 64 character random strings will make symbolic debugging
unpleasant.
Using 6.4 megabyte strings already makes symbolic debugging
unpleasant.
The one thing that
On Thursday, 19 May 2016 at 22:16:03 UTC, Walter Bright wrote:
On 5/19/2016 6:45 AM, Andrei Alexandrescu wrote:
I very much advocate slapping a 64-long random string for all
Voldermort returns
and calling it a day. I bet Liran's code will get a lot
quicker to build and
smaller to boot.
Let's
On Friday, 20 May 2016 at 05:34:15 UTC, default0 wrote:
On Thursday, 19 May 2016 at 22:16:03 UTC, Walter Bright wrote:
> (...)
(...) you still avoid generating a 5 Exabyte large symbol name
just to compress/hash/whatever it.
This is why compression is not good enough.
On Thursday, 19 May 2016 at 16:41:59 UTC, Andrei Alexandrescu
wrote:
On 05/19/2016 11:56 AM, Georgi D wrote:
Making a local copy of chain and moving the structure outside
of the
method solved the problem and reduced the code size.
The stripped size even reduced from the version that did not
e
On Thursday, 19 May 2016 at 22:16:03 UTC, Walter Bright wrote:
On 5/19/2016 6:45 AM, Andrei Alexandrescu wrote:
I very much advocate slapping a 64-long random string for all
Voldermort returns
and calling it a day. I bet Liran's code will get a lot
quicker to build and
smaller to boot.
Let's
On 5/19/16 6:16 PM, Walter Bright wrote:
On 5/19/2016 6:45 AM, Andrei Alexandrescu wrote:
I very much advocate slapping a 64-long random string for all
Voldermort returns
and calling it a day. I bet Liran's code will get a lot quicker to
build and
smaller to boot.
Let's see how far we get with
On Friday, 20 May 2016 at 09:48:15 UTC, ZombineDev wrote:
On Thursday, 19 May 2016 at 22:16:03 UTC, Walter Bright wrote:
On 5/19/2016 6:45 AM, Andrei Alexandrescu wrote:
I very much advocate slapping a 64-long random string for all
Voldermort returns
and calling it a day. I bet Liran's code wil
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
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...@digitalm
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 sugge
On Friday, 20 May 2016 at 10:54:18 UTC, Andrei Alexandrescu wrote:
On 5/19/16 6:16 PM, Walter Bright wrote:
On 5/19/2016 6:45 AM, Andrei Alexandrescu wrote:
I very much advocate slapping a 64-long random string for all
Voldermort returns
and calling it a day. I bet Liran's code will get a lot
On 05/20/2016 08:21 AM, Johan Engelen wrote:
On Friday, 20 May 2016 at 10:54:18 UTC, Andrei Alexandrescu wrote:
On 5/19/16 6:16 PM, Walter Bright wrote:
On 5/19/2016 6:45 AM, Andrei Alexandrescu wrote:
I very much advocate slapping a 64-long random string for all
Voldermort returns
and calling
On Friday, 20 May 2016 at 12:21:58 UTC, Johan Engelen wrote:
On Friday, 20 May 2016 at 10:54:18 UTC, Andrei Alexandrescu
wrote:
On 5/19/16 6:16 PM, Walter Bright wrote:
On 5/19/2016 6:45 AM, Andrei Alexandrescu wrote:
I very much advocate slapping a 64-long random string for all
Voldermort ret
On Friday, 20 May 2016 at 12:30:10 UTC, Andrei Alexandrescu wrote:
On 05/20/2016 08:21 AM, Johan Engelen wrote:
https://github.com/ldc-developers/ldc/pull/1445:
"Hashed symbols look like this:
_D3one3two5three3L3433_46a82aac733d8a4b3588d7fa8937aad66Result3fooZ
ddemangle gives:
one.two.three.L34
On Friday, 20 May 2016 at 12:57:40 UTC, ZombineDev wrote:
As I said earlier, it would be best if can prevent the
generation of long symbols in the first place, because that
would improve the compilation times significantly.
From what I've observed, generating the long symbol name itself
is
On 05/20/2016 09:07 AM, Johan Engelen wrote:
On Friday, 20 May 2016 at 12:30:10 UTC, Andrei Alexandrescu wrote:
On 05/20/2016 08:21 AM, Johan Engelen wrote:
https://github.com/ldc-developers/ldc/pull/1445:
"Hashed symbols look like this:
_D3one3two5three3L3433_46a82aac733d8a4b3588d7fa8937aad66
On Fri, May 20, 2016 at 09:24:42AM -0400, Andrei Alexandrescu via Digitalmars-d
wrote:
> On 05/20/2016 09:07 AM, Johan Engelen wrote:
[...]
> > One obstacle is the hasher itself: I am not going to implement one
> > myself! In the LDC PR, I used LLVM's MD5 hasher and Phobos's MD5
> > hasher. Perha
On Friday, 20 May 2016 at 13:24:42 UTC, Andrei Alexandrescu wrote:
I don't see a need for hashing something. Would a
randomly-generated string suffice?
That would break separate compilation, wouldn't it?
On Friday, 20 May 2016 at 12:08:37 UTC, ZombineDev wrote:
@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.fi
On Friday, 20 May 2016 at 15:39:18 UTC, Rene Zwanenburg wrote:
On Friday, 20 May 2016 at 12:08:37 UTC, ZombineDev wrote:
@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 thi
On Friday, 20 May 2016 at 13:16:32 UTC, Johan Engelen wrote:
On Friday, 20 May 2016 at 12:57:40 UTC, ZombineDev wrote:
As I said earlier, it would be best if can prevent the
generation of long symbols in the first place, because that
would improve the compilation times significantly.
From w
On Friday, 20 May 2016 at 13:24:42 UTC, Andrei Alexandrescu wrote:
I don't see a need for hashing something. Would a
randomly-generated string suffice?
Naïve question: is a (randomly-)?generated _anything_ required?
I've probably missed something, but it seems like line noise just
because
On Friday, 20 May 2016 at 17:11:52 UTC, Wyatt wrote:
I've probably missed something, but it seems like line noise
just because we feel we must.
Line and file is not unique because the same template would
generate different functions for different arguments.
Template arguments are a part of t
On Friday, 20 May 2016 at 16:21:55 UTC, ZombineDev wrote:
On Friday, 20 May 2016 at 13:16:32 UTC, Johan Engelen wrote:
On Friday, 20 May 2016 at 12:57:40 UTC, ZombineDev wrote:
As I said earlier, it would be best if can prevent the
generation of long symbols in the first place, because that
On 5/20/16 2:34 PM, Georgi D wrote:
1) Exponential growth of symbol name with voldemort types.
I like Steven's solution where the compiler lowers the struct outside of
the method.
Was talking to Walter on the phone and he just had one of those great
ideas: encode in the function mangle that it
On 5/20/2016 6:24 AM, Andrei Alexandrescu wrote:
I don't see a need for hashing something. Would a randomly-generated string
suffice?
Hashing produces reproducible unique values. Random will not be reproducible and
may not even be unique.
On 5/20/2016 5:57 AM, ZombineDev wrote:
Walter's PR slows down the compilation with
25-40% according to my tests. I expect that compilation would be faster if the
whole process is skipped altogether.
The compressor only kicks in if the string is longer than 64 bytes. I set it
pretty low in or
On 05/20/2016 03:45 PM, Walter Bright wrote:
On 5/20/2016 5:57 AM, ZombineDev wrote:
Walter's PR slows down the compilation with
25-40% according to my tests. I expect that compilation would be
faster if the
whole process is skipped altogether.
The compressor only kicks in if the string is lo
On Friday, 20 May 2016 at 19:41:16 UTC, Walter Bright wrote:
On 5/20/2016 6:24 AM, Andrei Alexandrescu wrote:
I don't see a need for hashing something. Would a
randomly-generated string
suffice?
Hashing produces reproducible unique values. Random will not be
reproducible and may not even be
On 5/20/2016 1:49 PM, Dicebot wrote:
The question is: is it actually good for them to be reproducible?
1. yes, because the same type can be generated from multiple compilation units
(the linker removes the duplicates - if they're not duplicates, the linker won't
remove them).
2. having the
On Friday, 20 May 2016 at 20:49:20 UTC, Dicebot wrote:
On Friday, 20 May 2016 at 19:41:16 UTC, Walter Bright wrote:
On 5/20/2016 6:24 AM, Andrei Alexandrescu wrote:
I don't see a need for hashing something. Would a
randomly-generated string
suffice?
Hashing produces reproducible unique value
On Friday, 20 May 2016 at 21:09:23 UTC, cym13 wrote:
It would make binary comparison of libraries and executables
difficult which troubles me as comparing hashes is a basics of
binary distribution security : you can check that a precompiled
binary is legit by recompiling it in the same conditio
On Fri, May 20, 2016 at 02:08:02PM -0700, Walter Bright via Digitalmars-d wrote:
[...]
> 2. having the compiler produce different .o files on different runs
> with the same inputs is pretty eyebrow raising, and makes it harder to
> debug the compiler, and harder to have a test suite for the compile
On Friday, 20 May 2016 at 19:37:23 UTC, Andrei Alexandrescu wrote:
On 5/20/16 2:34 PM, Georgi D wrote:
1) Exponential growth of symbol name with voldemort types.
I like Steven's solution where the compiler lowers the struct
outside of
the method.
Was talking to Walter on the phone and he jus
On Friday, 20 May 2016 at 22:01:21 UTC, Georgi D wrote:
This is a very interesting idea. I see one problem though: The
real issue is not just the return type but also the types of
the input parameters to a function. So even if the return type
of a method is encoded as "auto" the moment the resu
On Friday, 20 May 2016 at 19:45:36 UTC, Walter Bright wrote:
Hashing isn't algorithmically cheap, either.
I also don't think compression should be a performance issue. I
heard that some compression algorithms are as fast as the data
comes in, so fast enough for our purpose.
The reason I chos
On 05/20/2016 06:01 PM, Georgi D wrote:
In essence the problem that should be solved is the long names of types.
Voldemort returns are by far the worst. Compression and hashing should
handle the rest. -- Andrei
On Friday, 20 May 2016 at 21:09:23 UTC, cym13 wrote:
It would make binary comparison of libraries and executables
difficult which troubles me as comparing hashes is a basics of
binary distribution security : you can check that a precompiled
binary is legit by recompiling it in the same conditio
On Friday, 20 May 2016 at 19:41:16 UTC, Walter Bright wrote:
On 5/20/2016 6:24 AM, Andrei Alexandrescu wrote:
I don't see a need for hashing something. Would a
randomly-generated string
suffice?
Hashing produces reproducible unique values. Random will not be
reproducible and may not even be
On Saturday, 21 May 2016 at 01:29:18 UTC, Observer wrote:
My recollection is that successively compiled binaries are
rarely directly comparable, because of timestamps embedded by
compilers.
So I have to ask: are there standard tools to understand enough
of the ELF binary format (or whatever, f
On Saturday, 21 May 2016 at 01:35:05 UTC, Bill Hicks wrote:
On Friday, 20 May 2016 at 19:41:16 UTC, Walter Bright wrote:
Hashing produces reproducible unique values. Random will not
be reproducible and may not even be unique.
Just a troll here, but Quasirandom numbers are reproducible and
uni
On Saturday, 21 May 2016 at 02:16:30 UTC, Era Scarecrow wrote:
Unless there's a way to seed it consistently so order doesn't
matter, it won't work. Although a fast CRC32 on the source
could then give you a seed to work with, I'd prefer a hash over
PRNG.
There is no seed; it's a low-discrep
On Thursday, 19 May 2016 at 13:45:18 UTC, Andrei Alexandrescu
wrote:
On 05/19/2016 08:38 AM, Steven Schveighoffer wrote:
Yep. chain uses voldemort type, map does not.
We definitely need to fix Voldemort types. Walter and I bounced
a few ideas during DConf.
1. Do the cleartext/compress/hash
On Saturday, 21 May 2016 at 06:18:05 UTC, poliklosio wrote:
I have an Idea of reproducible, less-than-exponential time
mangling, although I don't know how actionable.
Leave mangling as is, but pretend that you are mangling
something different, for example when the input is
foo!(boo!(bar!(ba
On Friday, 20 May 2016 at 19:37:23 UTC, Andrei Alexandrescu wrote:
Was talking to Walter on the phone and he just had one of those
great ideas: encode in the function mangle that it returns
"auto". I thought that was fantastic. Would that work? -- Andrei
Equivalent to not mangling return type
On Saturday, 21 May 2016 at 17:34:19 UTC, Kagamin wrote:
On Friday, 20 May 2016 at 19:37:23 UTC, Andrei Alexandrescu
wrote:
Was talking to Walter on the phone and he just had one of
those great ideas: encode in the function mangle that it
returns "auto". I thought that was fantastic. Would that
On 05/21/2016 01:34 PM, Kagamin wrote:
But this leaves you with 2^^n growth, still exponential
He said that that won't happen any longer, the growth was because of the
return type. Is that correct? -- Andrei
On 5/20/2016 11:18 PM, poliklosio wrote:
I have an Idea of reproducible, less-than-exponential time mangling, although I
don't know how actionable.
Leave mangling as is, but pretend that you are mangling something different, for
example when the input is
foo!(boo!(bar!(baz!(int))), bar!(baz!(int
On Saturday, 21 May 2016 at 18:18:21 UTC, Andrei Alexandrescu
wrote:
He said that that won't happen any longer, the growth was
because of the return type. Is that correct?
https://issues.dlang.org/show_bug.cgi?id=15831#c4
Looks like growth is due to the fact that the voldemort type is
in the s
On Saturday, 21 May 2016 at 08:57:57 UTC, Johan Engelen wrote:
On Saturday, 21 May 2016 at 06:18:05 UTC, poliklosio wrote:
I have an Idea of reproducible, less-than-exponential time
mangling, although I don't know how actionable.
Leave mangling as is, but pretend that you are mangling
somet
On Saturday, 21 May 2016 at 18:25:46 UTC, Walter Bright wrote:
On 5/20/2016 11:18 PM, poliklosio wrote:
I have an Idea of reproducible, less-than-exponential time
mangling, although I
don't know how actionable.
Leave mangling as is, but pretend that you are mangling
something different, for
On Saturday, 21 May 2016 at 18:25:46 UTC, Walter Bright wrote:
On 5/20/2016 11:18 PM, poliklosio wrote:
foo!(boo!(bar!(baz!(int))), #1, #2)
Where #1 and #2 are special symbols that refer to stuff that
was **already in
the name**, particularly:
#1: bar!(baz!(int))
#2: baz!(int)
This is what L
On Saturday, 21 May 2016 at 17:34:19 UTC, Kagamin wrote:
Equivalent to not mangling return type at all. But this leaves
you with 2^^n growth, still exponential. Also is there any
evidence that compression is faster than hashing?
Depends on implementation and algorithm. However even the
weake
On 5/21/2016 1:09 PM, Era Scarecrow wrote:
Depends on implementation and algorithm. However even the weakest compression
settings can yield huge initial compression benefits. In normal text a reduction
of 2:1 is expected, and will . The benefit being compression still contains all
it's informati
On 5/21/2016 1:49 PM, Walter Bright wrote:
We already have a compressor in the compiler source for compressing names:
https://github.com/dlang/dmd/blob/master/src/backend/compress.c
A faster one would certainly be nice. Anyone game?
Note how well it does:
https://issues.dlang.org/show_bug.
On Saturday, 21 May 2016 at 20:50:56 UTC, Walter Bright wrote:
On 5/21/2016 1:49 PM, Walter Bright wrote:
We already have a compressor in the compiler source for
compressing names:
https://github.com/dlang/dmd/blob/master/src/backend/compress.c
A faster one would certainly be nice. Anyone
On 05/21/2016 06:27 PM, Anon wrote:
On Saturday, 21 May 2016 at 20:50:56 UTC, Walter Bright wrote:
On 5/21/2016 1:49 PM, Walter Bright wrote:
We already have a compressor in the compiler source for compressing
names:
https://github.com/dlang/dmd/blob/master/src/backend/compress.c
A faster one
On 05/21/2016 03:13 PM, Kagamin wrote:
On Saturday, 21 May 2016 at 18:18:21 UTC, Andrei Alexandrescu wrote:
He said that that won't happen any longer, the growth was because of
the return type. Is that correct?
https://issues.dlang.org/show_bug.cgi?id=15831#c4
Looks like growth is due to the f
On Sunday, 22 May 2016 at 21:40:07 UTC, Andrei Alexandrescu wrote:
On 05/21/2016 06:27 PM, Anon wrote:
On Saturday, 21 May 2016 at 20:50:56 UTC, Walter Bright wrote:
On 5/21/2016 1:49 PM, Walter Bright wrote:
We already have a compressor in the compiler source for
compressing
names:
https://
On 5/19/16 6:17 PM, Walter Bright wrote:
On 5/19/2016 8:39 AM, Steven Schveighoffer wrote:
template(T) foo if (someConstraints)
{
struct Result
{
T t;
}
auto foo(T t)
{
return Result(t);
}
}
This solution works awesomely, actually. It even produces smalle
On 5/22/16 5:42 PM, Andrei Alexandrescu wrote:
On 05/21/2016 03:13 PM, Kagamin wrote:
On Saturday, 21 May 2016 at 18:18:21 UTC, Andrei Alexandrescu wrote:
He said that that won't happen any longer, the growth was because of
the return type. Is that correct?
https://issues.dlang.org/show_bug.c
On 5/23/16 3:03 PM, Steven Schveighoffer wrote:
In fact, this may be a reason to NOT shortcut the return mangle
(if you had compiled against foo one day, and foo's internal voldemort
type changes the next, it would still link, even though the type may
have changed).
Actually, this is not true.
On 5/23/16 3:03 PM, Steven Schveighoffer wrote:
On 5/22/16 5:42 PM, Andrei Alexandrescu wrote:
On 05/21/2016 03:13 PM, Kagamin wrote:
On Saturday, 21 May 2016 at 18:18:21 UTC, Andrei Alexandrescu wrote:
He said that that won't happen any longer, the growth was because of
the return type. Is th
On 5/23/2016 12:03 PM, Steven Schveighoffer wrote:
Indeed, D does not overload based on return type ever.
It does factor into type matching when a function pointer is used, for example.
On 5/23/16 4:25 PM, Walter Bright wrote:
On 5/23/2016 12:03 PM, Steven Schveighoffer wrote:
Indeed, D does not overload based on return type ever.
It does factor into type matching when a function pointer is used, for
example.
Yes, that may be the only time return type is factored in, but
86 matches
Mail list logo
