On Monday, 27 August 2012 at 14:53:57 UTC, F i L wrote:
in C#, you use 'new Type()' for both classes and structs, and
it works fine. In fact, it has some benefit with generic
programming. Plus, it's impossible to completely get away from
having to understand the type, even in C++/D today, because we
can always make factory functions:
I'm sure in C# that all structs and classes are heap allocated
(It takes after C++ very likely) that's the simplest way to do
it. You can do that in C++ as well, but other than having to
declare it a pointer first. In C++ they made structs 'classes
that are public by default' by it's definition I believe.
Considering how C++ is set up that makes perfect sense.
FooType newFoo() {
return new FooType( ... );
}
void main() {
auto f = newFoo(); // struct or class?
}
By looking at newFoo I'd say a class; But if like in C# I'm
sure you can't tell the difference (But C++ with the pointer you
can). And for factory functions I'd put them inside the
struct/class, unless I had a compelling reason not to.
class Record {
static Record newRecord(string options) {
Record rec = new Record();
// stuff building the complex record
return rec;
}
}
However, I do agree it would be nice having some kind of
distinction between stack/heap allocation and copy/ref
semantics. Because constructor names are completely arbitrary
in my proposal, I think you could easily just choose a
different name (say, 'new' vs 'set').
struct Foo {
this set() { ... }
}
class Bar {
this new() { ... }
}
void main() {
auto f = Foo.set( ... ); // stack/copy
auto b = Bar.new( ... ); // heap/ref
}
Again, this is just an arbitrary distinction and wouldn't be
enforced, so third-party libs could choose something completely
different... but then, they always could (like above) so it's
benefit is debatable.
I've had ideas before about having two different '=' operators
for assignment and copy, but honestly, I think just looking up
and understanding the types you're working with might be the
best solution. A task much easier with proper IDE tooltips and
the like.
Would new still be a key word?
No. You could just as easily name your constructor
'freshCopyYo()'. In fact, you often want multiple constructor
names for different constructing procedures, like I explain in
my original post. For instance if you're loading from a file,
having a 'load()' constructor makes more sense than 'new()'.
When converting from some other type, have a 'from()'
constructor. The name implies the action, but they all
"construct" the type:
class Text
{
this new() // blank
this new(string s) // basic constructor
this from(int i) // convert from int
this from(float f) // convert from float
this load(string filename) // load from file
}
All of these are constructors, because they're return type is
'this'. They all implicitly allocate an object and have a
'this' reference. However, their names and implementations are
completely arbitrary, which is a good thing because we need and
use these arbitrary constructors all the time today, we just
have to do it in a completely inconsistent way (static factory
functions).
And a postblits would end up being...? The extra 'this' makes it
look like an obvious typo or a minor headache.
this this(this){} //postblitz?
Honestly I kinda like it how it is now. It's fairly clear and
concise. Only if you start getting creative can it begin to get
confusing; Then again in any language someone who decided to make
it confusing would make it confusing regardless.
--
enum JOJOJO = 100;
class Jo {
int jojo1;
Jo jo(Jo JOO) {
int jojo = 10;
int joJo = JOJOJO;
Jo JO = new Jo();
// and so on and so forth.
}
}
// Make a new Jo!
Jo newJo(){
return Jo.jo(null);
}
Jo something = newJo(); //now is this a class or a struct :P
Right back at you.
--
Seriously... Actually if you get it confusing enough you could
submit it to The International Obfuscated C Code Contest.
http://www.ioccc.org/
I would say if 'new' is part of the function name, it's returns
a class. If it's referenced (or a pointer), it could be either.
But not having a universal constructor would make creating an
array with defaults impossible without declaring/hinting which
one to use. It's one reason structs have to have good contents
for all it's data members at compile-time, so you could create an
array with defaulted information that works.
If we take your approach and suggestion, which one should the
compile assume?
Something globalSomething;
class Something {
this defaultConstructor();
this duplicate(); //or clone
this copyGlobalSomething();
this constructorWithDefault(int x = 100);
}
By signature alone... Which one? They are all legal, they are
uniquely named, and they are all equal candidates. Order of
functions are irrelevant.
