For the Builder pattern, you can also use a constructor w/ named params...seems more Kotlin idiomatic IMHO...
I agree for this particular example, but consider a class with more properties.
You generally don't want a constructor (or any other method) with five or more parameters.
The builder can also do more than just building the object. E.g. validating correct property-combinations, which is not something you should do inside a constructor.
I think one of the problems with your approach is theoretically possibility to have broken data, since constuction of object is separated from setting up field.
Approach with naming constructor parameters or more stable and looks like builder, since all preparations are happen in constructor of object. And if it will fail, you just will not receive a new object.
Sure, but separating construction from representation is the whole point of the Builder pattern.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.