profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/uael/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Lucas Abel uael @tempow alucas-@42 Paris http://uael.github.io Software architect

uael/42sh 14

42 shell school project, support for job-control, shell script, globbing, aliases, ..

uael/42piscine 10

Piscine C @42 - July 2017

grumbach/woody_woodpacker 8

A simple packer for Elf64 binaries

SpenderJ/BSQ 2

BSQ is a file parser, our program will receive one or more files, which are maps, in these maps, you will have to find the biggest square. We made our best so our BSQ can go as quick as possible, and use less memory as possible.

SpenderJ/Lem_in 1

42 2018 - Algorithmic project Lem-In

uael/42scripts 1

useful scripts @42

2ndcouteau/rush00 0

rush00 piscineC++

issue closedziglang/zig

[Proposal] Introduce optional types as a valid switch argument

Proposal

Introduce optional types as a valid switch argument.


// arg is an optional type, and null means "follow the parent orientation" for example
fn setOrientation(arg: ?Orientation) void {

      // allow switch over arg without unwrapping it
      switch (arg) {
          .Horizontal => ...
          .Vertical => ...
          // An exhaustive switch must handle all values plus the null option
          null => ...
      }
}

// arg is an optional type and null must be handled together with other values
fn checkPermissions(arg: ?Clearance) void {

      switch (arg) {
          .Allowed => ...
         // handle null and non-null values in the same block
          .Revoked, null => ... 
      }
}

// works with any type allowed in switch statements
fn setValue(arg: ?u32) void {

      switch (arg) {
          0 => ...
          1 => ...
          // Else can handle null values in non-exhaustives types
          else => ...
      }
}

Motivation

As null can be a meaningful value, makes sense to handle its value in the same switch statement. It improves the code readability and avoids related logic to be split across different control flows.

// same example in Zig status quo
fn setOrientation(arg: ?Orientation) void {

      if (arg) |non_null| {
            switch (non_null) {
                .Horizontal => ...
                .Vertical => ...
            }
      } else {
          // handles null here
      }

Workarround

For enums, define a None option instead of ? to representing the null value

closed time in an hour

batiati

issue commentziglang/zig

[Proposal] Introduce optional types as a valid switch argument

Rejected in #1545.

batiati

comment created time in an hour

issue commentziglang/zig

[Proposal] Introduce optional types as a valid switch argument

To be more fair, I think the following 2 would be the equivalent:

    // CURRENT SYNTAX:
    if (arg) |a| switch (a) {
        .Horizontal => ...
        .Vertical => ...
    } else {
        ...
    }

    // NEW SYNTAX:
    switch (a) {
        .Horizontal => ...
        .Vertical => ...
        null => ...
    }

One thing I didn't see explained was whan happens with optional exhaustive enums? Does else handle both null and unspecified values in that case?

Also what about a double optional ??T? Would the else case handle both null and null null? Or maybe a double optional wouldn't be supported?

The other issue is this adds support for 2 different ways of accomplishing the same thing. We'll have the current syntax and now another syntax. Unless we come up with some way to remove the old syntax? But I don't think that will work since not all optional values can be used inside a switch. Or maybe an idea is we don't allow "switchable" values to use the if (opt) |val| ... syntax?

batiati

comment created time in 2 hours

startedksh93/ksh

started time in 2 hours

startedRonsor/riscv-zig

started time in 5 hours

issue openedziglang/zig

[Proposal] Switch over a optional types

Proposal

Introduce optional types as a valid switch argument.


// arg is an optional type, and null means "follow the parent orientation" for example
fn setOrientation(arg: ?Orientation) void {

      // allow switch over arg without unwrapping it
      switch (arg) {
          .Horizontal => ...
          .Vertical => ...
          // An exhaustive switch must handle all values plus the null option
          null => ...
      }
}

// arg is an optional type and null must be handled together with other values
fn checkPermissions(arg: ?Clearance) void {

      switch (arg) {
          .Allowed => ...
         // handle null and non-null values in the same block
          .Revoked, null => ... 
      }
}

// works with any type allowed in switch statements
fn setValue(arg: ?u32) void {

      switch (arg) {
          0 => ...
          1 => ...
          // Else can handle null values in non-exhaustives types
          else => ...
      }
}

Motivation

As null can be a meaningful value, makes sense to handle its value in the same switch statement. It improves the code readability and avoids related logic to be split across different control flows.

// same example in Zig status quo
fn setOrientation(arg: ?Orientation) void {

      if (arg) |non_null| {
            switch (non_null) {
                .Horizontal => ...
                .Vertical => ...
            }
      } else {
          // handles null here
      }

Workarround

For enums, define a None option instead of ? to representing the null value

created time in 6 hours

issue commentziglang/zig

Proposal: Remove function aliasing and user named namespaces

For example https://github.com/Snektron/vulkan-zig, has removed all vk prefix from the vulkan functions because it expects the namespace to be vk.

My primary reason for removing the namespace is so that there is only one namespace - the Zig one - instead of both a Zig and a C namespace. The other option would have been to keep the C namespace and require the user to perform usingnamespace @import("vk.zig"); to deduplicate that namespace. In this scenario, and in the proposed change, it would be very hard to keep track of in which file a certain function is defined (with the status quo, one can simply look up where the namespace is assigned). This is my main concern with this proposal.

My other concern is related to nested namespaces. I think there are plenty of situations where that is required, and this proposal would either force me to write overly long namespaces or merge them all into one top-level namespace. Furthermore, i think that requiring absolute everywhere (i'm not sure if this proposal entails that) is quite inconsistent: If i'm writing code in some namespace X, then its against the common scoping rules that i would need to address X again when referencing some entity in that same namespace, even if its in a sub- or super namespace.

For myself, i consider const thing = @import("thing.zig"); clear enough to make up what namespace refers to what, even if thing is not the "intended namespace" for such a module.

kruseborn

comment created time in 9 hours

startedtroisjs/trois

started time in 10 hours

startedkuchin/awesome-cto

started time in 10 hours

startedjitsi/lib-jitsi-meet

started time in 10 hours

startedjitsi/lib-jitsi-meet

started time in 10 hours

startedsharkdp/bat

started time in 10 hours

startedsherlock-project/sherlock

started time in 10 hours

startedrudderlabs/rudder-server

started time in 10 hours

issue commentziglang/zig

@bitCast on same-size std.meta.Vector segfaults compiler

Indeed, that does fix it. While messing around I also noticed this:

    var foo = VecB{ 0, 0, 0, 0};
    var bar = @intCast(VecA, foo);
Code Generation [515/540] std.mem.Allocator.allocAdvancedWithRetAddr... LLVM ERROR: Cannot emit physreg copy instruction
[1]    77925 abort      zig build-exe crash.zig

Semantically an intCast there probably doesn't make sense, but it seems to be triggering an internal fatal error in llvm

ehaas

comment created time in 11 hours

issue commentziglang/zig

zig fmt mis-formats arrays with const/volatile

Indeed the decision is motivated by providing a better error message. If such a better error message is possible to implement in the parser, as you suggest, then I agree that is the best approach.

tadeokondrak

comment created time in 11 hours

PR opened ziglang/zig

std/crypto/chacha20: add round-reduced versions & cleanup internals

See https://eprint.iacr.org/2019/1492.pdf for justification.

8 rounds ChaCha20 provides a 2.5x speedup, and is still believed to be safe. Round-reduced versions are actually deployed (ex: Android filesystem encryption), and thanks to the magic of comptime, it doesn't take much to support them.

This also makes the ChaCha20 code more consistent with the Salsa20 code, removing internal functions that were not part of the public API any more.

No breaking changes; the public API remains backwards compatible.

+611 -573

0 comment

3 changed files

pr created time in 12 hours

issue commentziglang/zig

@bitCast on same-size std.meta.Vector segfaults compiler

The compiler is trying (and failing) to perform the bitcast at compile-time. Turn the const into var and it should work just fine.

ehaas

comment created time in 12 hours

issue commentziglang/zig

LLVM miscompiles some vector instructions for MIPS

Another LLVM patch.

LemonBoy

comment created time in 12 hours

issue commentziglang/zig

Proposal: Remove function aliasing and user named namespaces

Huh, I was just thinking about something like this yesterday. I don't think it's the language's job to prevent you from renaming modules/functions, but I do think it would be nice to have something that encourages using the original name for things.

kruseborn

comment created time in 13 hours

issue commentziglang/zig

@bitCast on same-size std.meta.Vector segfaults compiler

Running in lldb I get this:

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x8)
    frame #0: 0x0000000100acbf19 zig`buf_write_value_bytes(codegen=0x000000010a808200, buf="", val=0x0000000000000000) at ir.cpp:30329:22
   30326	}
   30327
   30328	static void buf_write_value_bytes(CodeGen *codegen, uint8_t *buf, ZigValue *val) {
-> 30329	    if (val->special == ConstValSpecialUndef) {
   30330	        expand_undef_struct(codegen, val);
   30331	        val->special = ConstValSpecialStatic;
   30332	    }
ehaas

comment created time in 13 hours

issue openedziglang/zig

@bitCast on same-size std.meta.Vector segfaults compiler

Version: 0.8.0-dev.1396+5bd9a6451 on macOS Big Sur x86_64

Example:

const std = @import("std");
const VecA = std.meta.Vector(8, u16);
const VecB = std.meta.Vector(4, u32);
pub fn main() u8 {
    const foo = VecA {1,1,1,1};
    const bar = @bitCast(VecB, foo);
    return 0;
}
~ zig build-exe crash.zig
[1]    67184 segmentation fault  zig build-exe crash.zig

created time in 14 hours

issue commentziglang/zig

zig fmt: Mixing comments and doc comments has weird results

These should be moved to 0.8.0.

squeek502

comment created time in 15 hours

issue commentziglang/zig

Proposal: Use a keyword instead of a colon in while loop continue expressions

Here is an alternative suggestion using then at the end:

const expect = @import("std").testing.expect;

test "while loop continue expression" {
    var i: usize = 0;
    while (i < 10) {} then {i += 1};
    expect(i == 10);
}

test "while loop continue expression, more complicated" {
    var i: usize = 1;
    var j: usize = 1;
    while (i * j < 2000) {
        const my_ij = i * j;
        expect(my_ij < 2000);
    } then {
        i *= 2;
        j *= 3;
    }
}

while can already have an else branch, so this feels like it would fit inbetween fairly naturally.

Rocknest

comment created time in 16 hours

issue commentziglang/zig

Proposal: Remove function aliasing and user named namespaces

But the problem is that you don't know what the scope is going to be. If you are expecting a specific scoped name, you may remove important information. If someone is writing, and probably will do, the context is lost.

const create = @import("opengl").Shader.create;
...
create(...);

It's the same as in C++. You are expecting someone to use the namespace, but then someone does: using namespace ...; And you end up with C++ best practices to tell developers to not use a specific feature, a feature that should not be there in the first place.

I'm totally okay with that. Zig is there to liberate the user from working around certain things and if it makes the code better if a global function create exists, i'm totally fine with that. Luckily, nearly nobody uses usingnamespace in zig except for some explicit module merging.

I see the status quo as a strength of zig, not as a weakness. It allows me to write the code i intent, not the workaround to express what i intent

kruseborn

comment created time in 18 hours

issue commentziglang/zig

Proposal: Remove function aliasing and user named namespaces

But the problem is that you don't know what the scope is going to be. If you are expecting a specific scoped name, you may remove important information. If someone is writing, and probably will do, the context is lost.

const create = @import("opengl").Shader.create;
...
create(...);

It's the same as in C++. You are expecting someone to use the namespace, but then someone does: using namespace ...; And you end up with C++ best practices to tell developers to not use a specific feature, a feature that should not be there in the first place.

kruseborn

comment created time in 18 hours

issue commentziglang/zig

Proposal: Remove function aliasing and user named namespaces

For example https://github.com/Snektron/vulkan-zig, has removed all vk prefix from the vulkan functions because it expects the namespace to be vk.

I don't think it's a very strong argument. I assume @Snektron removed the prefix because it's unnecessary. That prefix is a hack around that said global namespace of C and is not necessary at all in zig. If i now use vulkan.createInstance or vk.createInstance is my decision. Forcing me to type a unnecessy vk is worse, especially on readability as it conveys no information

And being able to solve symbol conflicts with file scope is very good. However, looking for a function name is a very common operation, and it would be nice to find a solution where tooling will not be the only way to solve it.

I have used this already quite extensively to improve APIs. Consider this: opengl.Shader.glCreateShader vs. opengl.Shader.create. They are the same function, but i don't want to encode redundant information in function names that are provided by scope. But i don't think it's common that people randomly rename functions for improved convenience

kruseborn

comment created time in 19 hours

issue commentziglang/zig

Runtime segfault in `.{ SomeStruct { .field = not_comptime_known } }`

The following produces a segmentation fault with 0.7.1 and zig-linux-x86_64-0.8.0-dev.1431+c760532be

    var x : i32 = 1;
    var y = .{ .{ x } };

Looks similar but I've only used zig for a couple of hours.

dbandstra

comment created time in 19 hours

issue commentziglang/zig

Proposal: Remove function aliasing and user named namespaces

My proposal was mostly to start a discussion about the topic. I agree that C++'s way of solving it by adding all namespaces to the global scope is not a good solution. And being able to solve symbol conflicts with file scope is very good. However, looking for a function name is a very common operation, and it would be nice to find a solution where tooling will not be the only way to solve it.

Something that could help with this is to only use file scope when you have a conflict. The normal case would be to write @import("foo/network.zig"); Then the author of the file will not expect a namespace. There are already zig libraries that assume what the namespace name will be. For example https://github.com/Snektron/vulkan-zig, has removed all vk prefix from the vulkan functions because it expects the namespace to be vk.

kruseborn

comment created time in 19 hours