Has the idea of function overloading via nogc been explored?

void func() @nogc
{
    // logic that does not use GC
}
void func()
{
    // logic that uses GC
}
void main(string[] args) // @nogc
{
    // if main is @nogc, then the @nogc version of func
    // will be called, otherwise, the GC version will be
    func();
}

This could be useful for the standard library to expose different implementations based on whether or not the application is using the GC.

"Jonathan Marler"  wrote in message news:huzhibjpuvqjxqnubsog@forum.dlang.org...

> Has the idea of function overloading via nogc been explored?
>
> void func() @nogc
> {
>      // logic that does not use GC
> }
> void func()
> {
>      // logic that uses GC
> }
> void main(string[] args) // @nogc
> {
>      // if main is @nogc, then the @nogc version of func
>      // will be called, otherwise, the GC version will be
>      func();
> }
>
> This could be useful for the standard library to expose different implementations based on whether or not the application is using the GC.

I think in most cases either the @nogc version would use different types (or it's templated), and therefore you wouldn't need to overload on @nogc, or you would simply have only a @nogc version. 

W dniu 2014-11-21 o 04:36, Jonathan Marler pisze:
> Has the idea of function overloading via nogc been explored?
>
> void func() @nogc
> {
>      // logic that does not use GC
> }
> void func()
> {
>      // logic that uses GC
> }
> void main(string[] args) // @nogc
> {
>      // if main is @nogc, then the @nogc version of func
>      // will be called, otherwise, the GC version will be
>      func();
> }
>
> This could be useful for the standard library to expose different
> implementations based on whether or not the application is using the GC.

+1

On 11/21/14, 12:36 AM, Jonathan Marler wrote:
> Has the idea of function overloading via nogc been explored?
>
> void func() @nogc
> {
>      // logic that does not use GC
> }
> void func()
> {
>      // logic that uses GC
> }
> void main(string[] args) // @nogc
> {
>      // if main is @nogc, then the @nogc version of func
>      // will be called, otherwise, the GC version will be
>      func();
> }
>
> This could be useful for the standard library to expose different
> implementations based on whether or not the application is using the GC.

If you have a version that doesn't use the GC, what's the reason to prefer one that uses it?

On Friday, 21 November 2014 at 03:36:30 UTC, Jonathan Marler wrote:
> Has the idea of function overloading via nogc been explored?
>
> void func() @nogc
> {
>     // logic that does not use GC
> }
> void func()
> {
>     // logic that uses GC
> }
> void main(string[] args) // @nogc
> {
>     // if main is @nogc, then the @nogc version of func
>     // will be called, otherwise, the GC version will be
>     func();
> }
>
> This could be useful for the standard library to expose different implementations based on whether or not the application is using the GC.

If you need temporary allocations on the heap, and already have an implementation using nogc anyways, it's better to do that even for the GC version.

The only difference I can see would be in returning values, and having whether the returned memory is managed by the GC or by the caller be based off the overload seems extremely dangerous. Template functions in particular could be either nogc or not with inference, and making the caller nogc shouldn't make it suddenly leak memory.

Instead consider passing in an allocator. Then it's explicit, more flexible, and more different.

On Sunday, 23 November 2014 at 08:57:15 UTC, Kapps wrote:
> Instead consider passing in an allocator. Then it's explicit, more flexible, and more different.

More apparent rather. Auto correct messed it up then hit send trying to touch the word to select it. -_-

On Saturday, 22 November 2014 at 16:56:58 UTC, Ary Borenszweig wrote:
> On 11/21/14, 12:36 AM, Jonathan Marler wrote:
>> Has the idea of function overloading via nogc been explored?
>>
>> void func() @nogc
>> {
>>     // logic that does not use GC
>> }
>> void func()
>> {
>>     // logic that uses GC
>> }
>> void main(string[] args) // @nogc
>> {
>>     // if main is @nogc, then the @nogc version of func
>>     // will be called, otherwise, the GC version will be
>>     func();
>> }
>>
>> This could be useful for the standard library to expose different
>> implementations based on whether or not the application is using the GC.
>
> If you have a version that doesn't use the GC, what's the reason to prefer one that uses it?

because, say, you can have two versions! Is that not good enough for you?

e.g., you can later on write a nogc version and simply switch between the two implementations by toggling the attribute on main.

Benefits? Easy:

1. It allows you to update your library to handle nogc progressively
2. It allows you to more easily debug your code. If it works with @gc and not @nogc then obviously it's in the @nogc code.
3. It reduces code bloat and confusion because one doesn't have to have multiple names of the same function floating around. e.g., allocate_gc, allocate_nogc_heap, etc.

The problem here is that such a rule chooses one or the other which reduces its usefulness. If one could simply request nogc functions, say, then

void main() @request(@nogc(heap))
{
    allocate();
    other_overload();
}

could attempt to use all @nogc overloads, in this case, the above expands to essentially

void main() @request(@nogc(heap))
{
    allocate_nogc_heap(); //
    other_overload_gc();   // assuming it exists, if not, it will use whatever overloads exist that
}

But with all this added complexity I don't think one gets a huge benefit in this case. Simply making the compiler GC agnostic and by using allocators, I think one gets basically the same functionality with more clarity.

It may work in other cases though. Essentially the concept is to extend overloading to work with attributes.

e.g.,

void func(...)
void func(...) @attr1
void func(...) @attr2

are all overloads with the attributes also being overloaded.

func@random(...)

calls a random overload(chosen at compile time).

func@request(@attr1)(...)

attempts to call func with @attr1 but falls back on the non-overloaded ones, etc.

func@attr1(...) calls the function with @attr1 or fails if it doesn't exist.

Ultimately, having such a metadata system helps partition similar functions in a program and then do something more complex.

Not sure if it would actually be that useful since we can effectively already do this type of stuff, albeit with more work and confusion.

W dniu 2014-11-22 o 17:56, Ary Borenszweig pisze:
> On 11/21/14, 12:36 AM, Jonathan Marler wrote:
>> Has the idea of function overloading via nogc been explored?
>>
>> void func() @nogc
>> {
>>      // logic that does not use GC
>> }
>> void func()
>> {
>>      // logic that uses GC
>> }
>> void main(string[] args) // @nogc
>> {
>>      // if main is @nogc, then the @nogc version of func
>>      // will be called, otherwise, the GC version will be
>>      func();
>> }
>>
>> This could be useful for the standard library to expose different
>> implementations based on whether or not the application is using the GC.
>
> If you have a version that doesn't use the GC, what's the reason to
> prefer one that uses it?

Some algorithms (that swap pointers very often) may run faster with GC, but GC can cause stalls in your real time code. Nogc at main() is about preventing those stalls, even if nogc function will run slower (f.i. because pointer swaping adds some overhead needed to manage ownership - think about RC pointers). But *if* you want to use GC, it's more desirable to use faster GC version.

On 11/21/2014 04:36 AM, Jonathan Marler wrote:
> This could be useful for the standard library to expose different
> implementations based on whether or not the application is using the GC.

https://issues.dlang.org/show_bug.cgi?id=9511