April 19, 2015
On Sunday, 19 April 2015 at 02:50:59 UTC, Rikki Cattermole wrote:
> So I went with closest I thought it was to make the point.

I don't understand what the point is... is it just syntax?
April 19, 2015
On 19/04/2015 11:48 p.m., Adam D. Ruppe wrote:
> On Sunday, 19 April 2015 at 02:50:59 UTC, Rikki Cattermole wrote:
>> So I went with closest I thought it was to make the point.
>
> I don't understand what the point is... is it just syntax?

I was just toying with different syntax's regarding allocation.
Atleast to me, none of them really fit.
April 19, 2015
On 2015-04-19 11:57, w0rp wrote:

> I'm not sure how that will
> end up looking in the end, but I am reminded of Objective C again, where
> allocation and construction are explicitly separated.
>
> // Enough time in Wonderland makes this seem perfectly natural.
> MyClass* foo = [[MyClass alloc] initWithNumber:3];

And in Swift they removed then need to call "alloc".

-- 
/Jacob Carlborg
April 21, 2015
On Saturday, 18 April 2015 at 15:24:27 UTC, w0rp wrote:
> @nogc
> void main() {
>     throw new Foo("Oh no!");
> }

Though until https://issues.dlang.org/show_bug.cgi?id=14119 is resolved the tracehandler GC allocates anyhow.
Why are malloc exceptions better then gc exceptions? Are you throwing so many of them that the GC becomes a bottleneck :)?
April 21, 2015
On Tue, 21 Apr 2015 22:53:15 +0000, Martin Nowak wrote:

> On Saturday, 18 April 2015 at 15:24:27 UTC, w0rp wrote:
>> @nogc void main() {
>>     throw new Foo("Oh no!");
>> }
> 
> Though until https://issues.dlang.org/show_bug.cgi?id=14119 is resolved
> the tracehandler GC allocates anyhow.
> Why are malloc exceptions better then gc exceptions? Are you throwing so
> many of them that the GC becomes a bottleneck :)?

the idea is to avoid allocations alltogether. malloc is a sample, one can use statically allocated pool instead, for example. this way functions can throw, yet still be @nogc.

April 23, 2015
On Saturday, 18 April 2015 at 15:24:27 UTC, w0rp wrote:
> The following code almost compiles.
>
> --------
> import core.stdc.stdlib;
>
> class Foo : Exception {
>     @nogc pure nothrow @safe
>     this(string msg, string file = __FILE__, size_t line = __LINE__, Throwable next = null) {
>         super(msg, file, line, next);
>     }
>
>     @nogc
>     new(size_t size) {
>         return malloc(size);
>     }
> }
>
> @nogc
> void main() {
>     throw new Foo("Oh no!");
> }
> --------
>
> That's right. An unofficially deprecated feature of the language and a newer feature of the language coming together in an interesting way. The only thing stopping this code from actually working is a trivial change to druntime to mark the Throwable, Exception, and Error constructors as @nogc, which I just created a pull request for directly through GitHub.
>
> https://github.com/D-Programming-Language/druntime/pull/1223
>
> Now imagine that instead of just a malloc which leaks memory like the above, other allocation schemes are used here instead. Consider also the coming addition to the language for class reference counting methods opAddRef and opRelease. Then let your imagination run wild.
>
> Enjoy!

I don't see anything interesting here. Controlling allocation was never the issue (MyException.create ftw). It is deallocation that matters.
1 2 3
Next ›   Last »