On Saturday, 17 June 2017 at 13:05:50 UTC, Adam D. Ruppe wrote:
> The reason writeln fails @nogc is that it *might* throw an exception with most args if stdout is closed or something.
>
> Perfect example of an *extremely* rare case failing @nogc's ridiculously strict requirements.

If that Walter's DIP about reference-counted exceptions gets trough it should ease problem like that quite a bit.

And as he said, memory-safe programming is not the problem -verifying the safety is. I think it is the same with GC.

Didn't Don Clugston say about something at some Dconf that it must trigger allocation "not hardly ever, NEVER"? So there's a real need even for the rigid @nogc, albeit a niche one.

On Saturday, 17 June 2017 at 13:09:42 UTC, Guillaume Piolat wrote:
> As a counterpoint: It's true that it's a bit niche, but when you have "no gc" then @nogc really helps with peace of mind (only one allocation and you may crash).

Yes, when you actually need it it might be helpful, and then the associated niche libraries might use it too.

Of course, you can still lie about the attributes...

On Saturday, 17 June 2017 at 16:59:56 UTC, Dukc wrote:
> If that Walter's DIP about reference-counted exceptions gets trough it should ease problem like that quite a bit.

Possibly. There's a lot of solutions to the exception thing though, and it doesn't actually bother me if you see @nogc as being very niche because you can just use one of those solutions today. (most of them depend simply on the catching code calling some disposal function, or living with a (possibly temporary) leak. Aside from that, the *most* you have to do is just `throw make!Exception` instead of `throw new Exception` and problem solved).

> Didn't Don Clugston say about something at some Dconf that it must trigger allocation "not hardly ever, NEVER"? So there's a real need even for the rigid @nogc, albeit a niche one.

Yes, there are a few cases for it, but most people on reddit aren't one of them.

It reminds me of the "web scale" thing. "but can this handle 1 million hits per second?" Probably not, but you also almost certainly going to need to... and if you do, the company will surely have the budget to hire a whole team of full time people to develop some specialized solution to their problem.

The D language should certainly never get in the way of those specialized solutions, whether scaling, or low latency audio/bidding, or whatever else, but I'm not convinced it needs to support them all out of the box either - and the average D user (or web developer in general) certainly doesn't have to worry.

On Friday, 16 June 2017 at 18:26:15 UTC, Joakim wrote:
> On Friday, 16 June 2017 at 13:51:18 UTC, Mike Parker wrote:
>> I've been meaning to get this done for weeks but have had a severe case of writer's block. The fact that I had no other posts ready to go this week and no time to write anything at all motivated me to make time for it and get it done anyway. My wife didn't complain when I told her I had to abandon our regular bedtime Netflix time block (though she did extract a concession that I have no vote in the next series we watch). Thanks to Vladimir, Guillaume, and Steve, for their great feedback on such short notice. Their assistance kept the blog from going quiet this week.
>>
>> The blog:
>> https://dlang.org/blog/2017/06/16/life-in-the-fast-lane/
>>
>> Reddit:
>> https://www.reddit.com/r/programming/comments/6hmlfq/life_in_the_fast_lane_using_d_without_the_gc/
>
> Nicely written.  I never bothered to look into this GC fine-tuning, as I don't need that level of optimization, but I finally have some idea of how this works.

And people have noticed, it's about to hit the top 10 most-liked proggit links of the last 7 days:

https://www.reddit.com/r/programming/top/?sort=top&t=week

One typo I forgot to mention earlier, where you wrote "aren't likey."

On 06/17/2017 10:39 AM, Adam D. Ruppe wrote:
> On Saturday, 17 June 2017 at 16:59:56 UTC, Dukc wrote:

>> Didn't Don Clugston say about something at some Dconf that it must
>> trigger allocation "not hardly ever, NEVER"? So there's a real need
>> even for the rigid @nogc, albeit a niche one.
>
> Yes, there are a few cases for it, but most people on reddit aren't one
> of them.
[...]
> and the average D user (or web developer in general)
> certainly doesn't have to worry.

I would like to see these ideas in a blog post. It's liberating when assumed problems are convinced away. :)

Ali

On Monday, 19 June 2017 at 00:12:25 UTC, Ali Çehreli wrote:
> I would like to see these ideas in a blog post. It's liberating when assumed problems are convinced away. :)

True, but I think the very blog post we're talking about already does that.

On 06/19/2017 12:12 AM, Dukc wrote:
> On Monday, 19 June 2017 at 00:12:25 UTC, Ali Çehreli wrote:
>> I would like to see these ideas in a blog post. It's liberating when
>> assumed problems are convinced away. :)
>
> True, but I think the very blog post we're talking about already does that.
>

LOL. You're right. :) I think I've been thinking more more about Adam's observations about @nogc. I've been thinking myself that it's unfortunate that throwing an exception makes a function no-@nogc. I know that there are efforts towards @nogc exceptions but I think @nogc should somehow related only to the normal operation of code. Since exceptions are for error cases, perhaps they shouldn't have an effect on whether a function is @nogc.

Ali

On Monday, 19 June 2017 at 10:13:33 UTC, Ali Çehreli wrote:
> I know that there are efforts towards @nogc exceptions but I think @nogc should somehow related only to the normal operation of code. Since exceptions are for error cases, perhaps they shouldn't have an effect on whether a function is @nogc.

This strikes me as making a lot of sense. You can compare it to the @system, @trusted and @safe trio, where @system is the default and @trusted could be verbosely translated as @unsafe_code_that_is_acceptable_to_be_called_in_safe_code_as_an_exception_to_the_rule.

Transferring this to GC, you could have @gc (the default), @nogc (the @safe equivalent) and the @trusted equivalent: @gc_code_that_is_acceptable_to_be_called_in_nogc_code_as_an_exception_to_the_rule. I'll abbreviate this as @gc78 until there is a better name.

With this, exceptions can be defined to be @gc78 to make them work in @nogc code: As exceptions are exceptional, one can argue that it is OK for them to do exceptional things.

Also, you can write a debugging function that uses string concatenation and writeln inside a DebugCondition, mark it as @gc78 and you'll still be able to call it in @nogc code. This won't cause collection in release versions.

Bastiaan.

On Tuesday, 20 June 2017 at 09:56:03 UTC, Bastiaan Veelo wrote:

> Transferring this to GC, you could have @gc (the default), @nogc (the @safe equivalent) and the @trusted equivalent: @gc_code_that_is_acceptable_to_be_called_in_nogc_code_as_an_exception_to_the_rule. I'll abbreviate this as @gc78 until there is a better name.

It can already be done:

void gc78writeln(string what) @nogc
{   import std.stdio;
    alias WritelnType = void function(string) @nogc;
    (cast(WritelnType)&writeln!string)(what);
}

void main() @nogc
{   import std.stdio;
    gc78writeln("hello world!");
}

I wasn't skilled enough to make a generic version of this trough. And I do not know what happens if @nogc function ends up calling gc.

On Tuesday, 20 June 2017 at 15:24:06 UTC, Dukc wrote:

>
> I wasn't skilled enough to make a generic version of this trough. And I do not know what happens if @nogc function ends up calling gc.

This seems like it only would work if you know that there wouldn't be any allocations. I don't really know though.

Below is a little more generic:

template gc78f(alias f)
{
    void gc78f(T...)(T what) @nogc
    {
        import std.stdio;
        alias fType = void function(T) @nogc;
        (cast(fType)&f!T)(what);
    }
}

void main() @nogc
{
    import std.stdio;
    string x = "hello world!";
    gc78f!(writeln)(x);
}