[rust-dev] Class UI

Niko Matsakis niko at alum.mit.edu
Thu Apr 12 06:58:00 PDT 2012

In fact, Rust separates initialization from allocation.  The OP was 
correct that new might better be called an initializer, but I think that 
ship has sailed---constructor is the generally accepted term for the 
function which initiailizes the instance, for better or worse.  Still, 
for a class C, it is possible to write C(...), @C(...), ~C(...) and so 
forth, each of which will allocate memory from a different location 
(stack, task heap, exchange heap).

With regions, it will also be possible to use user-specified memory 
pools.  The current syntax is `new(pool) C`, harkening back to 
overloaded-new in C++, but I am not sure if we'll stay with it.

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).


On 4/12/12 12:25 AM, Kobi Lurie wrote:
> what about a private new() in the class, that returns the allocated 
> instance, and a public 'make' fn, with how many overloads you want, to 
> serve as a ctor. rustc can require that atleast one 'make' fn will 
> exist for a class, and that it returns the same object that came from 
> new().
> (the user cannot write a fn named 'make', if it doesn't return the 
> class type, and the actual object from new().  -- if it's possible to 
> verify such a thing statically)
> bye, kobi
> On 4/12/2012 7:56 AM, Steven Blenkinsop wrote:
>> I don't know about your use of the term "constructor", but it is true
>> that "new" is often associated with the allocation side of things
>> instead of the initialization side of things in languages that make a
>> distinction (many don't). Go faces the opposite problem since people
>> think of "new" as syntax for calling a constructor which does
>> initialization, and its "new" does allocation. But maybe that just helps
>> prove your point, which is that people have strong preconceptions about
>> what "new" means, so it might be worthwhile for Rust to pick a different
>> word, all else being equal. I can't see it creating huge problems, since
>> the worst case scenario is that people will continuously be griping
>> about how "new" is the wrong word, but if you can minimize the number of
>> perennial meaningless complaints, you have more time to address real
>> problems.
>> _______________________________________________
>> Rust-dev mailing list
>> Rust-dev at mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
> _______________________________________________
> Rust-dev mailing list
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev

More information about the Rust-dev mailing list