[rust-dev] Class UI

Benjamin Striegel ben.striegel at gmail.com
Thu Apr 12 07:45:55 PDT 2012

Optional named parameters in function invocations could be a third option,
although of course that introduces a third inflexibility to consider. :P

So, which happens most often?

1) You create a class without any constructor besides property assignment,
and then later introduce a more substantial constructor.
2) You alter the order of fields/memory layout of a class.
3) You change the names of a class' fields.

On Thu, Apr 12, 2012 at 10:22 AM, Nate Bragg <jonathan.bragg at alum.rpi.edu>wrote:

> On Thu, Apr 12, 2012 at 9:58 AM, Niko Matsakis <niko at alum.mit.edu> wrote:
>> What I mainly dislike about the current constructor system is having to
>> repeat everything all the time.  Sometimes this is ok but usually a
>> constructor just wants to initialize all (or most) of the fields from the
>> values given in the parameters.  One possibility that patrick and I had
>> talked about is that if there is no constructor defined, one can construct
>> the class using a literal syntax like `C { f1: ..., f2: ... }`.  But I am
>> concerned that this is kind of discontinuous with the
>> constructor---implementing a constructor would then require rewriting every
>> allocation site.
>> So perhaps we should just say there is a default constructor of the form:
>>    new(f1: T1, ..., fN: T2) {
>>        self.f1 = f1;
>>        ...
>>        self.fN = fN;
>>    }
>> for each field `f1`, ..., `fN` defined in the class (and in the same
>> order as they are defined).
> Anecdotally, from the perspective of this prospective user, default
> constructors like that give me heartburn (for the first example that pops
> into my head, say two fields of the same type change in position inside the
> class - now you have to fix all of your default constructors).  If there is
> going to be an implicit constructor, I would prefer the literal style you
> listed.  It hearkens back to c99-style field-name designated initializers,
> and is very explicit.
> _______________________________________________
> Rust-dev mailing list
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20120412/d5768529/attachment.html>

More information about the Rust-dev mailing list