Passing default values to fields in a struct when using the value decorator

[daaa1m]

Is there a way to use the value decorator and have default arguments in a struct? As per below, I'm getting an error at the initialisation as well as when calling the struct.

@value
struct MyPet:
    var name: String
    var age: Int = 7 

[geo-mak]

You can't assign values when you declare fields, you must initialize them in the constructor init.
Ref: https://docs.modular.com/mojo/manual/structs

[daaa1m]

thanks but just to clarify, my question is whether it's possible to allow default values when declaring fields for structs w a value constructor given the point of the constructor is to cut down on the boilerplate for getting full value semantics. if we can't do default values when initialising here, it really limits the use of the value constructor

[geo-mak]

As far as I know, it is not possible, @value doesn't help with default values.

[rarebreed]

You could use rust's trick with a Default trait, and implement it for the struct.

trait Default:
    @staticmethod
    fn default() -> Self: ...

@value
struct MyPet(Default):
    var name: String
    var age: Int

    @staticmethod
    fn default() -> Self:
        return MyPet("", 7)

fn main():
    var pet = MyPet.default()

Since struct are compile time data, they have to be fully initialized once the program is running. It is a bit verbose to do it like that, but if you have a lot of fields that have sensible defaults, it is better than nothing.

Not sure if mojo will eventually allow default values in struct or not (they will have to for class types with class fields, since that is allowed in python).

[rarebreed]

honestly though, you're better off just implementing your own __init__ :) It will be more useful too.

@value
struct MyPet:
    var name: String
    var age: Int

    fn __init__(inout self, name: String):
        self.name = name
        self.age = 7

The @value decorator still gives you default constructors since mojo, unlike python, has the nicer feature of method overloading (which IMHO, is much nicer than only having default arguments). It can still be verbose if you have a lot of fields though. So I do hope mojo provides a shortcut way to assign defaults eventually.

Ideally, mojo will eventually give us decorator hooks for structs so we could do more metaprogramming on a struct in a pre-compile phase (so you could use something like python's dataclass decorator and field

[daaa1m]

yeah, the Rust trick really adds a layer of complexity and makes the code less readable imo - i guess just need to write the boilerplate then! thanks anyways!

[geo-mak]

Many ergonomics in python exist because there are many defaults made for you, backed by a costly VM and memory allocation model to figure things out at runtime (e.g., most types are heap-allocated).

It is a different language, and I hope they realize that sticking to the “pythonic” way with all of its legacy features in an attempt to attract Python users is not going to work. (Most python's users are not systems people)

Personally, I don’t mind if some of Python’s problematic or outdated features are removed, like dunder methods, which are “dunder” to distinguish them from user-defined methods in a programming model based on subclassing, not Traits! Other features like combining data with methods or dynamic classes with monkey patching..etc.

[geo-mak]

I’m not sure what is usually meant by 'systems programming languages', but to me, programming languages fall into two categories: general and domain-specific.

A general-purpose language must allow low-level programming and optimizations, such as implementing raw memory layouts, manipulating raw pointers, and directly interfacing with hardware instructions with minimal to no runtime support. Any language lacking these capabilities is, to me, a domain-specific language (e.g. Python, Ruby, Java).

In a broader sense, systems programming isn’t strictly about the language but a way of thinking. Systems programmers focus on:
A. The performance cost of every single line of code.
B. Scalability of the design without creating a massive, unmanageable system over time.

Now, regarding default arguments, they aren’t inherently bad, but in practice, they often lead to poor design. This is because every instance of a struct has to deal with them.

Python’s so-called 'ergonomics' aren’t actually ergonomics! they’re trade-offs. Most types in Python are heap-allocated with extensive type information, giving you great flexibility with runtime reflection but at the cost of terrible performance, not to mention the need for a VM.

Additionally, Python’s flexibility with typing makes it sloppy regarding type safety, and static type checkers are nearly useless in this regard. What you call 'ergonomics' is the result of trading off too much for flexibility. You can iterate faster, but eventually, you’ll hit a wall, unable to manage types or mutability chains in large codebases.

True ergonomics are when features enhance ease of use without compromising safety or performance. In other words, real ergonomics shouldn’t come with hidden costs in terms of runtime overhead or by sacrificing type safety.

Using Python for machine learning wasn’t a bad idea initially, as it’s great for experimental statistics where flexibility is an advantage. However, the scale at which it’s being used today makes it a "planet burner".

Writing data and ML infrastructure in Python is one of the worst experiences I’ve unfortunately been part of. Its so-called 'ergonomics' aren’t worth the messy code and abysmal performance, especially at today’s scale.

C is a low-level language but not a systems language. It’s primitive and sloppy regarding type safety, though it’s heavily used in systems because it’s old enough to be the de facto ABI for all OSes, with unchallenged support in the embedded space.

Zig is interesting in that it teaches you how to reinvent the flat wheel! There’s nothing in it that makes programming little bit better. It’s more of a lifestyle imperative language that ignores decades of language research!

Now, Mojo is still a work-in-progress and won’t satisfy everyone. It tries to make too many compromises, much like Swift, by mixing paradigms that shouldn’t be mixed, like OOP and ADTs.

Structs, as they are, with or without default values, are a bad idea when considering the complexity of type analysis and code clarity, as data and implementation are mixed. Rust have a much better model with clear separation. However, Mojo aims to be Python-like, which is an ancient language in almost every aspect of its design.

In any case, your have the right to complain and dislike things, but it’s up to the Mojo team to respond.