On Wednesday, 17 August 2016 at 18:24:37 UTC, Rory McGuire wrote:
On 17 Aug 2016 18:50, "Stefan Koch via Digitalmars-d-announce"
< digitalmars-d-announce@puremagic.com> wrote:
Just a small update today.
if(__ctfe) and if(!__ctfe)
now get special treatment.
Also working on getting
On 17 Aug 2016 18:50, "Stefan Koch via Digitalmars-d-announce" <
digitalmars-d-announce@puremagic.com> wrote:
>
> Just a small update today.
> if(__ctfe) and if(!__ctfe)
> now get special treatment.
> Also working on getting compiletime-parsers to run.
>
Nice tease with the "compile time parsers
Just a small update today.
if(__ctfe) and if(!__ctfe)
now get special treatment.
Also working on getting compiletime-parsers to run.
On Wed, 17 Aug 2016 13:53:37 +0300, Dicebot wrote:
> On 08/17/2016 04:01 AM, Chris Wright wrote:
>> On Tue, 16 Aug 2016 18:55:40 +, Dicebot wrote:
>>> You need to add one more level of indirection for things to start
>>> going complicated.
>>
>> Presumably scope is transitive, so things
Jacob Carlborg put together a guest post describing the history
and implementation of D Version manager. If you've never heard of
it, take a look. It's a useful utility to have installed.
Blog:
https://dlang.org/blog/2016/08/17/inside-d-version-manager/
Reddit:
On 08/17/2016 04:01 AM, Chris Wright wrote:
> On Tue, 16 Aug 2016 18:55:40 +, Dicebot wrote:
>> You need to add one more level of indirection for things to start going
>> complicated.
>
> Presumably scope is transitive, so things shouldn't get horribly complex.
It is not transitive and it is
On 08/17/2016 10:53 AM, Mike wrote:
> On Wednesday, 17 August 2016 at 07:17:24 UTC, Rory McGuire wrote:
>>
>>> If DIP1000 is implemented, it will change that behavior, so the
>>> allocation will instead be on the GC heap, but the compiler will do some
>>> flow-control analysis to prevent
On Wednesday, 17 August 2016 at 07:53:49 UTC, Mike wrote:
Got it! Thank you! But it still appears that what's
illustrated on the deprecations page is not being deprecated.
Mike
I imagine that will change if/when DIP1000 is accepted.
On Wednesday, 17 August 2016 at 07:17:24 UTC, Rory McGuire wrote:
If DIP1000 is implemented, it will change that behavior, so
the
allocation will instead be on the GC heap, but the compiler
will do some
flow-control analysis to prevent escaping references. Is that
right?
Mike
Not
On Wed, Aug 17, 2016 at 9:04 AM, Mike via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:
>
>
> Or perhaps DIP1000 changes the current behavior of the `scope` storage
> class.
>
> My understanding is that the `scope` storage class currently allocates a
> class on the stack
On Wednesday, 17 August 2016 at 07:04:26 UTC, Mike wrote:
Or perhaps DIP1000 changes the current behavior of the `scope`
storage class.
My understanding is that the `scope` storage class currently
allocates a class on the stack (though its usage for this
purpose is deprecated in favor of
On Wednesday, 17 August 2016 at 06:44:41 UTC, Mike wrote:
On Wednesday, 17 August 2016 at 04:28:33 UTC, Rory McGuire
wrote:
Basically DIP1000 makes it so that:
void main()
{
A obj;
{
scope A a = new A(1);
obj = a;
}
assert(obj.x == 1); // fails, 'a' has been
On Wednesday, 17 August 2016 at 04:28:33 UTC, Rory McGuire wrote:
Basically DIP1000 makes it so that:
void main()
{
A obj;
{
scope A a = new A(1);
obj = a;
}
assert(obj.x == 1); // fails, 'a' has been destroyed
}
Will not compile.
Ok, that makes sense. But
13 matches
Mail list logo
