After 1 year or something, I tried D again.

Do you know what happens if you write GC.Free insead of GC.free?

27 lines of code, 26 errors.

https://imgur.com/a/DlackXp

On Monday, 25 January 2021 at 15:07:02 UTC, Rumbu wrote:
> After 1 year or something, I tried D again.
>
> Do you know what happens if you write GC.Free insead of GC.free?
>
> 27 lines of code, 26 errors.
>
> https://imgur.com/a/DlackXp

It seems that we can do better on the syntax error checking front. Did you submit a bug report for this already?

-Alex

On Monday, 25 January 2021 at 15:07:02 UTC, Rumbu wrote:
> Do you know what happens if you write GC.Free insead of GC.free?

F.d(4): Error: no property Free for type GC, did you mean core.memory.GC.free?


There's gotta be something more to it on your end. My guess is some other import with a function called Free that is triggering all this ugliness.

D's error messages do suck.

Bigger problem with GC.free is it might not do what you think it does, be warned: https://issues.dlang.org/show_bug.cgi?id=21550

If you GC.malloc, it good, but if you `new int[]` then try to `GC.free` it is a silent no-op.

On Monday, 25 January 2021 at 16:11:28 UTC, Adam D. Ruppe wrote:
> On Monday, 25 January 2021 at 15:07:02 UTC, Rumbu wrote:
>> Do you know what happens if you write GC.Free insead of GC.free?
>
> F.d(4): Error: no property Free for type GC, did you mean core.memory.GC.free?
>
>
> There's gotta be something more to it on your end. My guess is some other import with a function called Free that is triggering all this ugliness.
>
> D's error messages do suck.
>
> Bigger problem with GC.free is it might not do what you think it does, be warned: https://issues.dlang.org/show_bug.cgi?id=21550
>
> If you GC.malloc, it good, but if you `new int[]` then try to `GC.free` it is a silent no-op.

These error messages are a common effort of Visual D and dmd. Sincerely I am not keen to investigate further, but if this is the first sight for a new user, he'll run.

I just made myself a new computer and tried to install everything I had in the past. Among other things, of course I had some hope for D after a year of ignoring each other :) VS Code plugin completely failed - debugger error and CMake takes over Dub. Unusable.

Tried Visual D, 20+ errors. First contact.

(On the GC: I have a MmFile class and I need to force it to close the mapped file, I don't know another way of deterministic call of the destructor except `scoped` but it's not the case)

On Monday, 25 January 2021 at 15:07:02 UTC, Rumbu wrote:
> ...Do you know what happens if you write GC.Free insead of GC.free?

Here I got:

main.d(8): Error: no property 'Free' for type 'GC', did you mean 'free'?

Matheus.

On Monday, 25 January 2021 at 15:07:02 UTC, Rumbu wrote:
> After 1 year or something, I tried D again.
>
> Do you know what happens if you write GC.Free insead of GC.free?
>
> 27 lines of code, 26 errors.
>
> https://imgur.com/a/DlackXp

Curious, why didn't u want to use new/delete/destroy?

On Monday, 25 January 2021 at 18:48:46 UTC, Imperatorn wrote:
> On Monday, 25 January 2021 at 15:07:02 UTC, Rumbu wrote:
>> After 1 year or something, I tried D again.
>>
>> Do you know what happens if you write GC.Free insead of GC.free?
>>
>> 27 lines of code, 26 errors.
>>
>> https://imgur.com/a/DlackXp
>
> Curious, why didn't u want to use new/delete/destroy?

iport std.mmfile;

struct Database
{
    this(string filename)
    {
        this.filename = filename;
        file = new MmFile(filename, MmFile.Mode.read, 0, null);
    }

    ~this()
    {
        if (file)
        {
            destroy(file);
            GC.free(&file);
        }
    }
}

//somewhere in code:
{
    Database db = Database("somefile");
    ....
    //here at the end of scope I want to be sure that file map is closed.
}

On Mon, Jan 25, 2021 at 07:53:11PM +0000, Rumbu via Digitalmars-d wrote: [...]
> iport std.mmfile;
> 
> struct Database
> {
>     this(string filename)
>     {
>         this.filename = filename;
>         file = new MmFile(filename, MmFile.Mode.read, 0, null);
>     }
> 
>     ~this()
>     {
>         if (file)
>         {
>             destroy(file);
>             GC.free(&file);
>         }
>     }
> }
> 
> //somewhere in code:
> {
>     Database db = Database("somefile");
>     ....
>     //here at the end of scope I want to be sure that file map is closed.
> }
[...]

Honestly, I think std.mmfile should either be refactored to be a struct with defined lifetime (i.e., with a dtor), or the class should have a .close method for explicitly closing the mapping.

Relying on a GC-collected object to reclaim a resource (in this case a mmap mapping) is an anti-pattern that should be expunged from Phobos.

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


T

-- 
Meat: euphemism for dead animal. -- Flora

On Monday, 25 January 2021 at 20:07:04 UTC, H. S. Teoh wrote:
> Relying on a GC-collected object to reclaim a resource (in this case a mmap mapping) is an anti-pattern that should be expunged from Phobos.
>
> 	https://issues.dlang.org/show_bug.cgi?id=9501
>
>
> T

Fully agree... it was brought up ages ago, I was living in the delusion that someone had fixed it by now... alas.

On Mon, Jan 25, 2021 at 09:26:28PM +0000, Tove via Digitalmars-d wrote:
> On Monday, 25 January 2021 at 20:07:04 UTC, H. S. Teoh wrote:
> > Relying on a GC-collected object to reclaim a resource (in this case a mmap mapping) is an anti-pattern that should be expunged from Phobos.
> > 
> > 	https://issues.dlang.org/show_bug.cgi?id=9501
[...]
> Fully agree... it was brought up ages ago, I was living in the delusion that someone had fixed it by now... alas.

I'd submit a PR for it, but based on the discussion in bugzilla, it probably won't go through, because (1) changing from a class to a struct will break pretty much *every* usage of it in existing code, and we're oh so afraid of breaking changes these days even if it's all for the better; (2) the anticipated back-n-forth on the ensuing PR discussion will probably wear me out and make me walk away as quickly as I approached.

Based on Andrei's and others' sentiment expressed within the past year or two, probably a more viable approach is to create a new mmfile API. Say std.mmfile2, or just have a new struct-based version of Mmfile alongside the current class, that has better semantics and better reflects today's language. (From the looks of it, std.mmfile was written in an earlier era where D still had a more class-centric, Java-like outlook, with one or two things bolted on afterwards but not really changing the core implementation.)  I'm wary of submitting this to Phobos, though, because the current PR process is a gigantic timesink and time is something I do not have enough of.

At this point, a dub package or some other external module is probably a better bet.  I'd try my hand at a standalone 1-file replacement for std.mmfile, but I've zero Windows dev experience so it will only be Posix-compatible.


T

-- 
Be in denial for long enough, and one day you'll deny yourself of things you wish you hadn't.