August 14, 2012 Re: Which D features to emphasize for academic review article | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mehrdad | On 8/14/2012 3:31 AM, Mehrdad wrote: > Then you get the best of both worlds: > > 1. You force the programmer to manually initialize the variable in most cases, > forcing him to think about the default value. It's almost no trouble for > > 2. In the cases where it's not possible, the language helps the programmer catch > bugs. > > > Why the heck D avoids #1, I have no idea. As I've explained before, user defined types have "default constructors". If builtin types do not, then you've got a barrier to writing generic code. Default initialization also applies to static arrays, tuples, structs and dynamic allocation. It seems a large inconsistency to complain about them only for local variables of basic types, and not for any aggregate type or user defined type. > It's one of the _major_ features of C# and Java that help promote correctness, > and #1 looks orthogonal to #2 to me. I know Java doesn't have default construction - does C#? As for the 'rarity' of the error I mentioned, yes, it is unusual. The trouble is when it creeps unexpectedly into otherwise working code that has been working for a long time. |
August 14, 2012 Re: Which D features to emphasize for academic review article | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Tuesday, 14 August 2012 at 21:13:01 UTC, Walter Bright wrote: > On 8/14/2012 3:31 AM, Mehrdad wrote: >> Then you get the best of both worlds: >> >> 1. You force the programmer to manually initialize the variable in most cases, >> forcing him to think about the default value. It's almost no trouble for >> >> 2. In the cases where it's not possible, the language helps the programmer catch >> bugs. >> >> >> Why the heck D avoids #1, I have no idea. > > As I've explained before, user defined types have "default constructors". If builtin types do not, then you've got a barrier to writing generic code. Just because they _have_ a default constructor doesn't mean the compiler should implicitly _call_ them on your behalf. C# and Java don't. >> It's one of the _major_ features of C# and Java that help promote correctness, and #1 looks orthogonal to #2 to me. > > I know Java doesn't have default construction - does C#? Huh? I think you completely misread my post... I was talking about "definite assignment", i.e. the _lack_ of automatic initialization. > As for the 'rarity' of the error I mentioned, yes, it is unusual. The trouble is when it creeps unexpectedly into otherwise working code that has been working for a long time. It's no "trouble" in practice, that's what I'm trying to say. It only looks like "trouble" if you look at it from the C/C++ perspective instead of the C#/Java perspective. |
August 14, 2012 Re: Which D features to emphasize for academic review article | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mehrdad | On Tuesday, 14 August 2012 at 21:22:14 UTC, Mehrdad wrote:
> C# and Java don't.
Typo, scratch Java, it's N/A for Java.
|
August 14, 2012 Re: Which D features to emphasize for academic review article | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mehrdad | On 8/14/2012 2:22 PM, Mehrdad wrote:
> I was talking about "definite assignment", i.e. the _lack_ of automatic
> initialization.
I know. How does that fit in with default construction?
|
August 14, 2012 Re: Which D features to emphasize for academic review article | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Tuesday, 14 August 2012 at 21:58:20 UTC, Walter Bright wrote:
> On 8/14/2012 2:22 PM, Mehrdad wrote:
>> I was talking about "definite assignment", i.e. the _lack_ of automatic initialization.
>
> I know. How does that fit in with default construction?
They aren't called unless the user calls them.
void Bar<T>(T value) { }
void Foo<T>()
where T : new() // generic constraint for default constructor
{
T uninitialized;
T initialized = new T();
Bar(initialized); // error
Bar(uninitialized); // OK
}
void Test() { Foo<int>(); Foo<Object>(); }
D could take a similar approach.
|
August 14, 2012 Re: Which D features to emphasize for academic review article | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mehrdad | On Tuesday, 14 August 2012 at 22:57:26 UTC, Mehrdad wrote:
> Bar(initialized); // error
> Bar(uninitialized); // OK
Er, other way around I mean...
|
August 15, 2012 Re: Which D features to emphasize for academic review article | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mehrdad | On 8/14/2012 3:57 PM, Mehrdad wrote: >> I know. How does that fit in with default construction? > They aren't called unless the user calls them. I guess they aren't really default constructors, then <g>. So what happens when you allocate an array of them? > D could take a similar approach. It could, but default construction is better (!). |
August 15, 2012 Re: Which D features to emphasize for academic review article | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Wednesday, 15 August 2012 at 00:32:43 UTC, Walter Bright wrote: > On 8/14/2012 3:57 PM, Mehrdad wrote: > I guess they aren't really default constructors, then <g>. I say potayto, you say potahto... :P > So what happens when you allocate an array of them? For arrays, they're called automatically. Well, OK, that's a bit of a simplification. It's what happens from the user perspective, not the compiler's (or runtime's). Here's the full story. And please read it carefully, since I'm __not__ saying D should adopt what C# does word for word! In C#: - You can define a custom default constructor for classes, but not structs. - Structs _always_ have a zero-initializing default (no-parameter) constructor. - Therefore, there is no such thing as "copy construction"; it's bitwise-copied. - Ctors for _structs_ MUST initialize every field (or call the default ctor) - Ctors for _classes_ don't have this restriction. - Since initialization is "Cheap", the runtime _always_ does it, for _security_. - The above^ is IRRELEVANT to the compiler! * It enforces initialization where it can. * It explicitly tells the runtime to auto-initialize when it can't. -- You can ONLY take the address of a variable in unsafe{} blocks. -- This implies you know what you're doing, so it's not a problem. What D would do _ideally_, IMO: 1. Keep the ability to define default (no-args) and postblit constructors. 2. _Always_ force the programmer to initialize _all_ variables explicitly. * No, this is NOT what C++ does. * Yes, it is tested & DOES work well in practice. But NOT in the C++ mindset. * If the programmer _needs_ vars to be uninitialized, he can say = void. * If the programmer wants NaNs, he can just say = T.init. Bingo. It should work pretty darn well, if you actually give it a try. (Don't believe me? Put it behind a compiler switch, and see how many people start using it, and how many of them [don't] complain about it!) >> D could take a similar approach. > > It could, but default construction is better (!). Well, that's so convincing, I'm left speechless! |
Copyright © 1999-2021 by the D Language Foundation