On Wednesday, 16 April 2014 at 10:13:06 UTC, bearophile wrote:
> JN:
>
>> I doubt @nogc will change anything, people will just start complaining about limitations of @nogc
>
> Having a way to say "this piece of program doesn't cause heap activity" is quite useful for certain piece of code. It makes a difference in both performance and safety.
> But not being able to call core.stdc.stdlib.alloca in a "@nogc pure" function sub-three is not good.
>
> Bye,
> bearophile

What about adding custom annotations that don't do any checking by
itself. Like when @nogc doesn't actually verify that the
~ is not used for strings.

void hello() require(@nogc)
{

}

Just a verification by the compiler that you use only routines
that are marked with certain annotations.

void boe()
{
}

@(nasaverified)
void test()
{
}

//

void hello() require(@(nasaverified))
{
  test(); // ok
  boe();  // not ok.
}

On Tuesday, 15 April 2014 at 21:41:37 UTC, Brad Anderson wrote:
> Yes, please. Too few of the attributes have inverse attributes.
>
> Being able to stick your defaults up at the top of your module and then overriding them only when needed would be very nice and make the code a lot more tidy.

I actually think this will make code harder to read. e.g.:

@nogc:

void foo()
{
   ...
}

void bar() @gc
{
   ...
}

@gc
{
   void baz() @nogc
   {
      ...
   }
}

@gc:

void quxx() @nogc
{
   ...
}

Ewww... nasty stuff.

On Wednesday, 16 April 2014 at 17:22:02 UTC, Gary Willoughby
wrote:
> On Tuesday, 15 April 2014 at 21:41:37 UTC, Brad Anderson wrote:
>> Yes, please. Too few of the attributes have inverse attributes.
>>
>> Being able to stick your defaults up at the top of your module and then overriding them only when needed would be very nice and make the code a lot more tidy.
>
> I actually think this will make code harder to read. e.g.:
>
> @nogc:
>
> void foo()
> {
>    ...
> }
>
> void bar() @gc
> {
>    ...
> }
>
> @gc
> {
>    void baz() @nogc
>    {
>       ...
>    }
> }
>
> @gc:
>
> void quxx() @nogc
> {
>    ...
> }
>
> Ewww... nasty stuff.

My point was opposite attributes complicate the code hugely.

On 4/16/2014 2:03 AM, JN wrote:
> I'd have to agree. I doubt @nogc will change anything, people will just start
> complaining about limitations of @nogc (no array concat, having to use own
> libraries which may be incompatible with phobos). The complaints mostly come
> from the fact that D wants to offer a choice, in other languages people just
> accept what they have. You don't see C# developers complaining much about having
> to use GC, or C++ programmers all over the world asking for GC. Well, most of
> the new games (Unity3D) are done in C# nowadays and people live with it even
> though game development is one of the biggest C++ loving and GC hating crowd
> there is.

We have to try. Especially since @nogc is a low risk thing - it doesn't break anything, and is a fairly simple addition to the compiler.


> Another issue is the quality of D garbage collector, but adding alternative
> memory management ways doesn't help, fragmenting the codebase.

No improvement to the GC is acceptable to people who want to manually manage memory. That much is quite clear.

On 4/16/2014 4:50 AM, Manu via Digitalmars-d wrote:
> I am convinced that ARC would be acceptable,

ARC has very serious problems with bloat and performance.

Every time a copy is made of a pointer, the ref count must be dealt with, engendering bloat and slowdown. C++ deals with this by providing all kinds of ways to bypass doing this, but the trouble is such is totally unsafe.

Further problems with ARC are inability to mix ARC references with non-ARC references, seriously hampering generic code.

> and I've never heard anyone suggest
> any proposal/fantasy/imaginary GC implementation that would be acceptable...

Exactly.


> In complete absence of a path towards an acceptable GC implementation, I'd
> prefer to see people that know what they're talking about explore how
> refcounting could be used instead.
> GC backed ARC sounds like it would acceptably automate the circular reference
> catching that people fuss about, while still providing a workable solution for
> embedded/realtime users; disable(/don't link) the backing GC, make sure you mark
> weak references properly.

I have, and I've worked with a couple others here on it, and have completely failed at coming up with a workable, safe, non-bloated, performant way of doing pervasive ARC.

On 4/16/2014 8:01 AM, qznc wrote:
> However, what is still an open issue is that @nogc can be stopped by allocations
> in another thread. We need threads which are not affected by stop-the-world. As
> far as I know, creating threads via pthreads C API directly achieves that, but
> integration with @nogc could provide more type safety. Stuff for another DIP?

That's a completely separate issue.

On 4/16/2014 1:49 AM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> Btw, I think you should add @noalloc also which prevents both new and malloc. It
> would be useful for real time callbacks, interrupt handlers etc.

Not practical. malloc() is only one way of allocating memory - user defined custom allocators are commonplace.

On Wednesday, 16 April 2014 at 17:39:32 UTC, Walter Bright wrote:
> Not practical. malloc() is only one way of allocating memory - user defined custom allocators are commonplace.

What I want is a __trait that scans for all call expressions in a particular function and returns all those functions.

Then, we can check them for UDAs using the regular way and start to implement library defined things like @safe, @nogc, etc. (safe and gc are a bit different because they also are affected by built-in language features, not just functions, but the same idea of recursively scanning for an annotation in the function body).

Of course, this wouldn't always be perfect, separate compilation could be used to lie about or hide annotations in a function prototype, but meh I don't really care about that, the main use for me would eb static asserts right under the function definition anyway.

Walter Bright:

> Not practical. malloc() is only one way of allocating memory - user defined custom allocators are commonplace.

OK, then I'll have to close my ER about @noheap.

Bye,
bearophile

On Tuesday, 15 April 2014 at 17:01:38 UTC, Walter Bright wrote:
> http://wiki.dlang.org/DIP60
>
> Start on implementation:
>
> https://github.com/D-Programming-Language/dmd/pull/3455

Some initial thoughts:

* Is it perhaps too early to introduce this? We don't have allocators yet, so it can be quite hard to avoid the GC in some situations.

* Many Phobos functions use 'text' and 'format' in asserts. What should be done about those?

* Does @nogc => nothrow? If I'm not mistaken, throw must through a GC-allocated Throwable.

* If the above is true, does that mean exceptions cannot be used at all in @nogc code?

* I worry about the number of attributes being added. Where do we draw the line? Are we going to add every attribute that someone finds a use for? @logicalconst @nonrecursive @nonreentrant @guaranteedtermination @neverreturns