View mode: basic / threaded / horizontal-split · Log in · Help
August 14, 2012
Re: Which D features to emphasize for academic review article
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
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
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
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
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
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
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
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!
Next ›   Last »
4 5 6 7 8
Top | Discussion index | About this forum | D home