Am Wed, 19 Oct 2016 19:25:39 +0000
schrieb TheGag96 <thegag96@gmail.com>:

> On Wednesday, 19 October 2016 at 03:29:10 UTC, Marco Leise wrote:
> > On the other hand LDC subjectively offers a couple more D specific enhancements, like turning GC allocations into stack allocations in trivial cases
> 
> Whoa, seriously? I know it's a bit off-topic, but do you have a code example of where this would happen? That's amazing!

Sorry, I don't have a concrete example. David Nadlinger keeps
emphasizing that the escape analysis is extremely simple. Try
a function with only "auto test = new Object;" in it and
extend from there using the "-vgc" switch to see when it
starts to fail.

-- 
Marco

On Thursday, 20 October 2016 at 05:43:47 UTC, Nick Sabalausky wrote:
>> And GDC is using the 2.068 feature set, plus a lot of bug fixes from
>> later versions.  I guess you could call it 2.068.5.  :-)
>>
>
> Maybe there's a certain amount of truth to that, but not completely: In all my projects anyway, the latest available GDC on travis always broke at exactly the same time DMD 2.066 and below broke.

i believe that Iain talked about frontend features. phobos is still at 2.066, i think.

> Not sure what your point is here. If you're writing a library and want to avoid giving your users deprecation messages due to the import changes, then you need to test on 2.070 or newer. Clean compilation on pre-2.070 does not guarantee clean compilation on 2.070+.

actually, any import deprecation messages may come only from sloppy coding, like using "implicitly imported identifier from 3rd module". tbh, none of my code ever triggered such a warning when DMD finally (almost) fixed it's import scheme. not 'cause i am a brilliant, but 'cause doing it "D way" (local selective imports in the closest scope) almost automatically prevents such bugs.

On 10/20/2016 08:21 AM, ketmar wrote:
> On Thursday, 20 October 2016 at 05:43:47 UTC, Nick Sabalausky wrote:
>> Not sure what your point is here. If you're writing a library and want
>> to avoid giving your users deprecation messages due to the import
>> changes, then you need to test on 2.070 or newer. Clean compilation on
>> pre-2.070 does not guarantee clean compilation on 2.070+.
>
> actually, any import deprecation messages may come only from sloppy
> coding, like using "implicitly imported identifier from 3rd module".
> tbh, none of my code ever triggered such a warning when DMD finally
> (almost) fixed it's import scheme. not 'cause i am a brilliant, but
> 'cause doing it "D way" (local selective imports in the closest scope)
> almost automatically prevents such bugs.

I hit tons of messages, mostly because of FQN now being more broken than ever.

On Thursday, 20 October 2016 at 16:03:32 UTC, Nick Sabalausky wrote:
> On 10/20/2016 08:21 AM, ketmar wrote:
>> On Thursday, 20 October 2016 at 05:43:47 UTC, Nick Sabalausky wrote:
>>> Not sure what your point is here. If you're writing a library and want
>>> to avoid giving your users deprecation messages due to the import
>>> changes, then you need to test on 2.070 or newer. Clean compilation on
>>> pre-2.070 does not guarantee clean compilation on 2.070+.
>>
>> actually, any import deprecation messages may come only from sloppy
>> coding, like using "implicitly imported identifier from 3rd module".
>> tbh, none of my code ever triggered such a warning when DMD finally
>> (almost) fixed it's import scheme. not 'cause i am a brilliant, but
>> 'cause doing it "D way" (local selective imports in the closest scope)
>> almost automatically prevents such bugs.
>
> I hit tons of messages, mostly because of FQN now being more broken than ever.

that's why i added "(almost)" part. there was another word, but i did self-censoring.

Am Thu, 20 Oct 2016 12:21:34 +0000
schrieb ketmar <ketmar@ketmar.no-ip.org>:

> On Thursday, 20 October 2016 at 05:43:47 UTC, Nick Sabalausky wrote:
> >> And GDC is using the 2.068 feature set, plus a lot of bug
> >> fixes from
> >> later versions.  I guess you could call it 2.068.5.  :-)
> >> 
> >
> > Maybe there's a certain amount of truth to that, but not completely: In all my projects anyway, the latest available GDC on travis always broke at exactly the same time DMD 2.066 and below broke.
> 
> i believe that Iain talked about frontend features. phobos is still at 2.066, i think.

GDC git is completely 2.068.2. There are no updated binary releases as there's still one remaining blocker regression (32bit only).

On Friday, 21 October 2016 at 19:53:14 UTC, Johannes Pfau wrote:
> GDC git is completely 2.068.2. There are no updated binary releases as there's still one remaining blocker regression (32bit only).

sorry for spreading false info then.