#Zag: C++ but its Zig++

1 messages · Page 1 of 1 (latest)

nova socket
#

chat can we ban this guy?

whole trench
cobalt geyser
#

Generally, you'd post something in #1024381264213594242 if you actually have something to show.

whole trench
cobalt geyser
#

That said, how would you change Zig to have guaranteed memory safety?

whole trench
#

and the compiler would get rid of the surprises you get too

cobalt geyser
#

But my allocators grief

whole trench
#

without changing it in the code

#

if you have any suggestions make sure to drop them here

#

:)

tired pollen
whole trench
# tired pollen Automatic in what way 
const std = @import("std");

fn doStuff(allocator: std.mem.Allocator) ![]u8 {
    var buffer = try allocator.alloc(u8, 10);
    defer allocator.free(buffer);
    return buffer;
}

instead of this it can be

fn doStuff() []u8 {
    return new u8[10]; // automatic allocation (e.g., ref-counted)
} 
```and it would be automatically freed when unused
crude vine
#

This is a good troll

whole trench
#

am i wrong about it?

tired pollen
#

Ok well the first one is just UB

#

You are returning freed memory

#

It also doesn’t answer my question

#

How will it know memory is unused

whole trench
nova socket
whole trench
#

my thinking will change soon

lavish ether
#

I don't understand what part of this remains zig. Just call it new language and move on, otherwise this is just a caricature of zig

whole trench
#

my keyboard

#

gboard is so good

peak iron
#

(but you shouldnt)

tired pollen
#

One of the points of zig is that memory management is manual

#

So idk why you would make an extension of zig that doesn’t have manual memory management

crude vine
#

At that point you've almost recreated Go

lavish ether
whole trench
#

:0

cobalt geyser
#

Was a joke, but my thoughts for a Zig++:

image.png
#

And the only one I was half-way serious about was a stable ABI

tired pollen
#

Oh god the ++ operator

cobalt geyser
#

Zig doesn't want its own stable ABI, because it likes being able to rearrange memory layout and stuff automatically, for optimization reasons.

tired pollen
#

How would operator overloading work with allocators

cobalt geyser
#

Yeah, passing an allocator into x += 42; seems awkward, lol. Only option would be to use a global allocator there, or at least pass it in through some other means (meaning any type with overloaded operators would need to embed the allocator ahead of time)

sly gate
#

to get operator overload to work with allocators you would probably have to do a nono and set up some implicit behavior.

#

so inside a function you'd have to do something like have a matrix state that implements the operators in scope and you would give the matrix state some allocator or something like that.

#

i can't think of any other way off hand to do it nicely, or perhaps put the expressions inside some call like Matrix.op(allocator, mata + matb * matc);

#

although it might be some comptimes already do this by passin the expression as a comptime string: Matrix.op(allocator, "mata + matb * matc");

plain wadi
#

A lot of people here probably won't see a need for a Zig++. All the features that you say are missing were intentionally excluded, and Zig users generally understand the reasoning and are happy without those features (which is why they use Zig)

chrome sonnet
#

you better off making a rust fork or something similar to vale