Skip to content

Instantly share code, notes, and snippets.

@pfgithub
Last active April 1, 2020 08:28
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save pfgithub/387bf434fc86d86bc39f5d651d72f700 to your computer and use it in GitHub Desktop.
Save pfgithub/387bf434fc86d86bc39f5d651d72f700 to your computer and use it in GitHub Desktop.
zig suggestions for the first day of the month

zig suggestions for the first day of the month

only one number type

zig is very confusing because it has so many number types. u16, i64, f32? what does all this mean‽ zig should follow the path of similar languages and simplify this down to one number type. I propose u0 because it can fill in for any other number type with a minimal loss of precision and takes less memory to store.

exceptions

instead of the confusing explicit error returns, zig should have untyped exceptions. that way, you have to be on edge every time you call a function and you have to worry if it might decide to error. it's especially nice because the errors shouldn't be mentioned in the docs. this makes programming more fun and exciting whenever you encounter a new error that you didn't know about.

fn main() void {
  try {
    runApp();
  } catch {
    alert("Uh oh! Something went wrong. Error code {x}.", .{crypto.randomBytes()});
    showCrashReporter();
  }
}

along with this, the inline try syntax should be replaced with a block try statement.

oop classes

all functions now should be associated with a data type. this will make it more clear what the functions are related to. there will be no ambiguity that comes from this because all functions always have a clear data type that is the only type they operate on. along with this, parameters and return values should be removed and all functions should only operate on the new implicit this value that is a pointer to the class data. also, we should not allow static functions and instead require all functions be on instances of classes.

const AdderClass = class {
  total: i64,
  toAdd: i64,
  add() {
    this.total += this.toAdd;
  }
}

pub const MainClass = class {
  pub fn main() {
    var adder = new AdderClass();
    adder.total = 25;
    adder.toAdd = 36;
    adder.add();
    
    var logMessage = new StdLibNamespace
      .StdLibLoggerNamespace
      .StdLibLoggerWarningLogMessageClass();
    logMessage.logTemplate = "Value is: {}";
    logMessage.logArgs = .{adder.total};
    logMessage.log();
  }
}

ternary operator

using clear if syntax for inline if statements is very confusing. zig should upgrade to the ternary operator that other languages use and remove if expressions.

if(a == 1) q()
else if(m())
  if(b()) f()
  else r(); // confusing

a == 1 ? q() : m() ? a() ? b() : f() : r(); // simple

ide build system

the zig build system should be removed entirely, and instead, IDEs should completely manage the building of zig projects. Every IDE should have its own structure for project files and build configuration. To make things simpler for newcomers, IDEs should only manage build configuration in GUI interfaces that is different per IDE, and IDEs should save absolute paths to projects within the configuration files they use. This change will make it easier to share open source projects online that anyone can edit and build and make zig more inviting to newcomers.

get rid of variable capturing syntax

|v|? this is very confusing for newcomers. instead, we should require that everyone types things twice

if(optional) |value| std.debug.warn("v: {}", .{value}); // too confusing
if(optional) std.debug.warn("v: {}", .{optional.?}); // very simple and not error-prone

switch(getEvent()) { .KeyDown => |kd| std.debug.warn("keydown event: {}", .{kd}) }; // what is even going on here‽

var event = getEvent();
switch(event) { .KeyDown => std.debug.warn("keydown event: {}", .{event.KeyDown}) }; // clear and unambiguous

nullable pointers

pointers should be able to be null, and if null pointers are used in a library, it should not be mentioned in the documentation or in code examples. this will help promote the good coding practice of checking for null on every pointer.

var memory = allocator.init(MyStruct);
if(memory == null) return error.AllocFailed;

The .init() function takes a struct and returns a pointer to the allocated memory.

remove translate-c

too many libraries are written in c, which is a very bad language because it is not zig. instead, we should completely give up on interoperability with existing languages and rewrite all code in zig.

ordered top level declaration

zig should require that all top level declarations are in order to make things more clear.

ast

to make ordered top level declarations easier, zig should have macros that can manage the ast of a source file. a macro like @include could parse the entire zig source being included and embed it in the ast directly. an @ifndef macro could only add certain code to the ast if a macro variable is not defined.

garbage collection

managing memory manually is hard. zig should do garbage collection. along with this, custom allocators should be removed and instead allocation should be implicit with a new keyword, new.

modifying parameter values

parameters should be var, just like they are in any sane language. also, they should all be implicit pointers so if you modify a parameter inside a function it should change the variable outside the function.

remove all operators

operators are bad because there is no operator overloading. to fix this, all builtin operators should be handled by functions like @intAdd(a, b) and @greaterThan(a, b).

interpereted language

zig should be an interpereted language instead of a compiled one. the compiletime system should be extended to allow syscalls, and all runtime functions should be removed.

different syntax for type definition

const a = struct {}? this implies that struct is a value that you can hold in a variable! to make it more clear to new users, we should have different syntax for type definition type a = struct {} and we should completely seperate the namespaces of types and variables like typescript does. also, we should remove bad functions that conflate the two like @typeInfo and ask users to write ast-generating macros instead.

type StructName = struct {};
const Variable = StructName; // undefined variable StructName
const value: Variable = 25; // undefined type Variable

automatic semicolons

semicolons are annoying. zig should automatically put a seimcolon at every newline character. if you ever need something to span multiple lines, you should be required to put a \ at the end of the line to clarify.

syntactic sugar for stdlib functions

lots of stdlib functions are annoying because there is no syntax for them. zig should add unicode symbols and keywords like 🖨️ for std.debug.warn and copy for std.mem.copy. keywords should be one word only and be common things people might want to use as variable or function names.

copy text[5..text.len] text[6..text.len - 1];
🖨️ "{}", text;

remove optionals

the optional type should be removed. optionals are useless, an untagged enum is just as good.

fn Optional(comptime T: type) type {
  return union{
    None: void,
    Some: T,
  };
}

whitespace sensitivity

typing curly braces and parenthesis is annoying, instead, the next line having an additional indent should mean that a curly brace was opened and the next line having two indents should mean that a parenthesis was opened.

fn main
		) !void
	std.debug.warn
		"hello, {}", .
	"world" }); }

to prevent any ambiguity between number of spaces, zig should use hard tabs ( ).

rich text support

zig should support open rich text formats for its files, like xhtml+css. this way, programmers can write their zig code in a wysiwig xhtml text editor and format their code to be easily readable with sans-serif fonts and double spacing between lines.

"goto" switch statements

having to exhaustively use all of the types of an enum or union is very annoying. zig should make goto-style switch statements with fallthrough

switch(event) {
.KeyDown =>
  app.handleKeyDownEvent(event.KeyDown);
  break;
.KeyUp =>
  app.handleKeyUpEvent(event.KeyUp);
  break;
}

ai compiler

the zig compiler should use ai to determine the code you wanted to write if you write a syntax error. also, it should be able to speak english so you should be able to make a zig program

hello zig compiler could you please make me an iot device like uber but for cross-compiling web apps? by the end of april fools day please? I will give you 10% of the revenue and I take the other 90% for coming up with the great idea.

if ai is too complicated, the zig compiler should hire someone for $2/hour to make this program and charge your bank accout with information it steals from your computer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment