Fixing C++ by making unions better

Jack Delahunt — Tue, 12 Jul 2022 18:23:34 +0000

In the past, I have gone through some of my issues with C++ and how I think I can improve the language. To do this I am currently creating my own language called ‘Liam’. I have gone over basic syntax and features in a past post here but today I am focusing on the new “Typed Unions” feature.

A full walkthrough of this in video form is on my channel here.

We have all experienced the deeply nested hierarchies of Object-Oriented Programming and asked ourselves “Is there a better way”? Well, I think C++ and as inherited from C already had a pretty good answer.

For me at least the vast majority of my inheritance comes down to wanting to group many different types into one with some common members or functions across them. For example, in Liam I have a ‘Statement’ struct that is inherited by many other statement types like ‘IfStatement’, ‘ScopeStatement’, and so on. It is nice to bundle these up and refer to them as just ‘Statement’ as I may not need or care about what I am referring to.

You can somewhat simulate this in C with the use of a union containing many structs and having some id of which type the union is currently.

struct Statement {

    StatementType type;

    union {
        IfStatement if_statement;
        ScopeStatement scope_statement;
        LetStatement let_statement;
    };

};

This gives the same functionality of inheritance but there is one issue, you must always check the if of the statement. While this is not normally unsafe it can lead to problems like when not initializing the type still gives a valid value.

To try and help with this I added Typed Unions to my language and here is how they work. You can see in the image below the type specifier for ‘x’ is multiple types separated by a pipe denoting and or semantic.

fn main(): void {
    let x: u64 | bool | str = "hello sailor!";
}

This shows the value of x might be a number, a boolean, or a string but it is not known for sure. This can also be extended to struct types to replicate the behavior in C’s unions. But there is still one more thing and that is how to get the actual value from x in a type-safe way.

fn main(): void {
    let x: u64 | bool | str = "hello sailor!";

    if x is str as_string {
        println[str](*as_string);
    }
}

All you do is a ‘is expression’, this just returns true if the value currently stored in the variable is the one we are asking, and if so it gives us a pointer to that value which in this example is the ‘as_string’ identifier. This new identifier is also scoped to the if block meaning this can be repeated for multiple types.

Another area in which this is useful is error handling. I personally really love how Zig does error handling and these new Typed Unions can get us that.

fn main(): void {
    if add(10, -20) is u64 n {
        print[u64](*n);
    }
}

fn add(x: i64, y: i64): u64 | str {
    let result := x + y;
    if result < 0 {
        return "Error negative number";
    }
}

This example is a bit more involved but you can see that the return of my add function is now either a number or a string where the string is my error message. I can then check if my function call was completed by using the is expression shown before.

If you like this post or want to contribute to the language go and check it out on github here.

Fixing C++ with a new open source project

Jack Delahunt — Sun, 03 Jul 2022 00:31:18 +0000

If you have ever written any code in C++ I first want to say sorry for all the needless pain you have been through but I am trying to make your life easier.

Many people have given their opinion on C++ and why they either don't like it or why you should never use it. Personally I actually do like C++ for the most part but there are some very obvious issues that can be addressed.

The first problem is how C++ compilers deal with parts of your code needing other parts and how it doesn't deal with them at all. Use before declaration and out of order declarations are normal and expected in a normal language and C++ does not and will not ever have this. You can see how old school C++ really is when you have to start thinking about header files and how they are included. These are just issues that shouldn't exist anymore.

// its 2022 this should work...
struct Bar {
   Foo foo;
};

struct Foo {};

C++ also has an issue of trying to be every language in existence all at once. To this day I don't think a single person knows what every keyword means and most still don't know all the ways to use static. Normally I wouldn't be annoyed by this but the fact that using seven keywords in a function declaration is considered "best practice" is enough for me to bring it up.

// how Bjarne Stroustrup writes foo examples
virtual int inline long constexpr volatile unsigned const long foo() const noexcept = delete;

I couldn't bring up the flaws of C++ without talking about the STL. It is honestly the saddest part of the language. Want to see the data within this object when debugging? Want to have short compile times? Want to know how and when your memory is being deallocated? Well good luck because the STL fails on all of these issues.

This is where my new and hopefully improved solution comes in but with some asterisks. My goal is to create a language as simple as C but with more modern features that C++ also provides but correctly this time. There is no need to complicate the language itself as we do not need extra problems to solve as developers, this is where languages such as C and Go inspired me.

Some things my language has or plans of having.

Easy to use generic functions and structs
Absolutely 0 exceptions
Absolutely 0 constructors
Absolutely 0 destructors
Clear separation of static strings and mutable ones
Absolutely 0 private anything
Custom allocators that you can be set project wide (including stdlib)
Absolutely 0 header files
Declare your structs and functions in any order
Auto pretty printing of any struct

I said before there were some asterisks to all this. While C++ has a lot of issues with has a huge amount of support, every library you know is probably usable in C or C++ and throwing that all out would be a shame. That is my Liam generates C++, and in fact the standard library for Liam is all written in C++ but just made available in Liam through some features in the language. To get people to leave C++ I do need to keep it around just long enough so people can jump ship.

The plan is to have already written C++ code made available in Liam without having to rewrite libraries all over again currently this is still in development but basic features are working.

Here is some syntax samples of the language, everything here is working and already implemented.

import "stdlib/io.liam";

struct Person {
   name: String,
   age: u64
}

fn main(): u64 {
    let person := new Person {
        # this is not cpp new does not heap alloc
        make_string("your name"),
        25
    };

    print[String](person.name);
}

Please checkout and even contribute here. I would love to see what the community can do for the project.

DEV Community: Jack Delahunt

Fixing C++ by making unions better

Fixing C++ with a new open source project