Haven't watched the ng for a while, but I was curious on a couple of things.

1.) Could we perhaps put a lot of the proposals for const on a wiki? I like the discussions that are going around it, but I must admit that they're all starting to really, really blend together.

2.) Between here and d.learn there's starting to get a lot of valuable information coming in as answers to other programmers queries. Could dsource.org or similar setup a basic faq system so we maybe there can be some cross posting of the answers to something more accessible?

Wouldn't take much I wouldn't think, tagging would take care of the categorization, or I guess we could just start it on the wiki. Should help with a lot of the duplicate requests too (and would be a bonus if some of the feature requests that have been hashed out over and over had a place there, along with decided rationale.)

3.) A language feature.  Thoughts on something similar on the following?
After a lot of tests, and a lot of debate we're heading towards a full port over time to D and only D, so we can get out of the c, ruby, and java entanglement we've been in for years.

On the java side we've been running into what I'd consider language implementation cruft that we're having to bring over.

class Show
{
  ...
}
...
function orig_func(Show s) {
	if (s !is null)
		
}

...
function some_func(enforce Show s) {
	// s is never null.

}
Show s = new Show();
some_func(s);	//ok
some_func(null);// error

I hate the idea of playing "i need another keyword", but I can't really see how it could be done and backwards compatible.

Anyways, what I'm in hopes of finding is a way to tell the compiler that I never want null, ever. I want an instance of the class and that's that. The whole idea of taking every lil runtime hit for checking  and the code cruft for writing it when in fact it's something that seems to be easy for a compiler to do the work for me.

Unless I'm missing something? Or an obvious hindrance to this entire thought process?

4.) SWT. Yeah, *that* SWT.
	We're considering sponsoring the inital port of SWT over to D for Linux and Windows (during hobby time I'd love to do a mac, but I'll have to grab a mini to get it going). I'm trying to get upper management to allow me to take a few weeks to run through the Windows implementation at first. We'll see if they let me.

We're trying to simplify our tooling and development requirements over 2008. We have a lot of SWT based code and developers used to developing for it. So it's why a port is being considered. (The main contender funny enough is xulrunner (read:mozilla) sigh).

SWT has a yearly release cycle and a fairly static api, so once it's built it shouldn't be too hard to keep up. From what I can tell what hurt DWT is D's volatility at the time more than Eclipse's. (and of course no one to work on it).

Tioport being a java translator has a couple of faults that aren't something we could jump in and just fix. The jni cruft that is in SWT gets translated into a D that doesn't even look like D. classes that should be structs in internals.* for one. I'm not knocking the tool, but it's clear that the overhead it's already producing that putting javaisms into D directly by means of translation feels cumbersome.

So knowing I'm heading into Monday needing to make a decent case for the cost of the SWT port I'm looking to see if there would be interest in help maintaining and enhancing an SWT port should I do all of the heavy lifting?

With Eclipse running well on Vista it seems that we'll at least be pretty forward looking on the windows side of things and from what I can tell the linux gtk side of things seems a lot simpler to do anyways.

Anyways, Food for thought.

Back to work.

Robby wrote:
> Anyways, what I'm in hopes of finding is a way to tell the compiler that I never want null, ever. I want an instance of the class and that's that. The whole idea of taking every lil runtime hit for checking  and the code cruft for writing it when in fact it's something that seems to be easy for a compiler to do the work for me.

The hardware will do the check for null pointer for you every time you do a dereference.

Walter Bright schrieb:
> Robby wrote:
>> Anyways, what I'm in hopes of finding is a way to tell the compiler that I never want null, ever. I want an instance of the class and that's that. The whole idea of taking every lil runtime hit for checking  and the code cruft for writing it when in fact it's something that seems to be easy for a compiler to do the work for me.
> 
> The hardware will do the check for null pointer for you every time you do a dereference.

I think he is talking about compile time check.
Something like non nullable storage class?

Walter Bright wrote:
> Robby wrote:
>> Anyways, what I'm in hopes of finding is a way to tell the compiler that I never want null, ever. I want an instance of the class and that's that. The whole idea of taking every lil runtime hit for checking  and the code cruft for writing it when in fact it's something that seems to be easy for a compiler to do the work for me.
> 
> The hardware will do the check for null pointer for you every time you do a dereference.

<summary>

Non-nullable types != null deref exceptions.
Non-nullable types > null deref exceptions.
Non-nullable types > contracts.

</summary>

<rant>

That's not the point.  Null dereference errors aren't all that helpful.
 They tell you that something's gone wrong, but they don't tell you *why*.

Let's pretend for a moment that appending '@' to an object type makes it a non-nullable type.  For example:

    Object@ o = null;

That would be a *compile-time error* since Object@s cannot be null.  It also means that (in the general case) this won't work:

    Object o1 = new Object;
    Object@ o2 = o1;

That's because o1 could possibly contain a null.  So in order to do this, you'd have to check that o1 is not null, and then cast.  Heck, the compiler could even do that for you:

    Object@ o2 = cast(@) o1

Why is this better than a null dereference exception?  Because it will
throw the exception when you try to *introduce the null* into your
program's state, *not* when you try to use it.  Normally, all a null
dereference tells you is that somewhere along the line, you screwed up.
 This tells you *when* you screw up.

What's more, this makes code cleaner, easier to check, and faster. Instead of having this all over the place:

    // the_object is a parameter, and could be null, so we'd best check
    // it!  We can't assert directly or the check will be elided in
    // -release builds.
    if( the_object is null ) assert(false);

...we need only check exactly once: where we introduce the object. After that, there's zero runtime cost, since we've already guaranteed that the reference is not null.  This is unlike contracts and invariants which exact an overhead, not to mention the fact that you can always either forget to write the assertion, or write it incorrectly.

Tim Sweeny (the lead programmer at Epic) once commented that the majority of bugs in the Unreal engine were caused by null dereferences; they knew the bugs were there, they just couldn't work out where the nulls were coming from.  He said he'd kill to have non-nullable objects in C++. [1]

This is something I've wanted for ages [2], if only for all the checks it would let me not write.  I understand that there are lots of things people want you to implement, and you can't fit them all in.  But don't mistake this for null dereference exceptions.

	-- Daniel

[1] I'm recalling from memory; too tired to go tracking down the paper itself.  Something about the next big programming language for games. Incidentally, he put his money on a Haskell-style language with C-style syntax.  And non-nullable types. :P

[2] Actually, what I *really* want is some form of type constraints. Something like:

    alias real:{$ != 0 && $ == $} real_not_zero_or_nan;

    Assuming '$' means "current value".  At the moment, the best tool we
have for this is, unfortunately, Hungarian notation (apps Hungarian, not
that pointless system Hungarian.)

</rant>

Frank Benoit wrote:
> Walter Bright schrieb:
>> Robby wrote:
>>> Anyways, what I'm in hopes of finding is a way to tell the compiler
>>> that I never want null, ever. I want an instance of the class and
>>> that's that. The whole idea of taking every lil runtime hit for
>>> checking  and the code cruft for writing it when in fact it's
>>> something that seems to be easy for a compiler to do the work for me.
>> The hardware will do the check for null pointer for you every time you
>> do a dereference.
> 
> I think he is talking about compile time check.
> Something like non nullable storage class?

Exactly.

Having a storage class 'enforce' that only allows non nullable types allows has a few advantages as far as I see it.

It's self documenting. It gives a contractual saftey to the implementor of the method/function. and it removes a lot of the cruft that the compiler already knows. (which is something I took notice D tends to do on a lot of other things.)

I know that the general consensus around D tends to be c/c++, but there's a solid selling point for us Java shops too, and this is one crufty piece that is littered through our code we'd really like to try and remove at some point.

Daniel Keep wrote:
> 
> Walter Bright wrote:
>> Robby wrote:
>>> Anyways, what I'm in hopes of finding is a way to tell the compiler
>>> that I never want null, ever. I want an instance of the class and
>>> that's that. The whole idea of taking every lil runtime hit for
>>> checking  and the code cruft for writing it when in fact it's
>>> something that seems to be easy for a compiler to do the work for me.
>> The hardware will do the check for null pointer for you every time you
>> do a dereference.
> 
> <summary>
> 
> Non-nullable types != null deref exceptions.
> Non-nullable types > null deref exceptions.
> Non-nullable types > contracts.
> 
> </summary>
> 
> <rant>
> 
> That's not the point.  Null dereference errors aren't all that helpful.
>  They tell you that something's gone wrong, but they don't tell you *why*.
> 
> Let's pretend for a moment that appending '@' to an object type makes it
> a non-nullable type.  For example:
> 
>     Object@ o = null;
> 
> That would be a *compile-time error* since Object@s cannot be null.  It
> also means that (in the general case) this won't work:
> 
>     Object o1 = new Object;
>     Object@ o2 = o1;
> 
> That's because o1 could possibly contain a null.  So in order to do
> this, you'd have to check that o1 is not null, and then cast.  Heck, the
> compiler could even do that for you:
> 
>     Object@ o2 = cast(@) o1
> 
> Why is this better than a null dereference exception?  Because it will
> throw the exception when you try to *introduce the null* into your
> program's state, *not* when you try to use it.  Normally, all a null
> dereference tells you is that somewhere along the line, you screwed up.
>  This tells you *when* you screw up.
> 
> What's more, this makes code cleaner, easier to check, and faster.
> Instead of having this all over the place:
> 
>     // the_object is a parameter, and could be null, so we'd best check
>     // it!  We can't assert directly or the check will be elided in
>     // -release builds.
>     if( the_object is null ) assert(false);
> 
> ....we need only check exactly once: where we introduce the object.
> After that, there's zero runtime cost, since we've already guaranteed
> that the reference is not null.  This is unlike contracts and invariants
> which exact an overhead, not to mention the fact that you can always
> either forget to write the assertion, or write it incorrectly.
> 
> Tim Sweeny (the lead programmer at Epic) once commented that the
> majority of bugs in the Unreal engine were caused by null dereferences;
> they knew the bugs were there, they just couldn't work out where the
> nulls were coming from.  He said he'd kill to have non-nullable objects
> in C++. [1]
> 
> This is something I've wanted for ages [2], if only for all the checks
> it would let me not write.  I understand that there are lots of things
> people want you to implement, and you can't fit them all in.  But don't
> mistake this for null dereference exceptions.
> 
> 	-- Daniel
> 
> [1] I'm recalling from memory; too tired to go tracking down the paper
> itself.  Something about the next big programming language for games.
> Incidentally, he put his money on a Haskell-style language with C-style
> syntax.  And non-nullable types. :P
> 
> [2] Actually, what I *really* want is some form of type constraints.
> Something like:
> 
>     alias real:{$ != 0 && $ == $} real_not_zero_or_nan;
> 
>     Assuming '$' means "current value".  At the moment, the best tool we
> have for this is, unfortunately, Hungarian notation (apps Hungarian, not
> that pointless system Hungarian.)
> 
> </rant>
Totally agree.

I was thinking more in the lines of having the 'contract' within the function/method declaration rather than having it with the object passing so that the api could have the final say, rather than the object passing in. And a storage class does have a backwards compat story without adding anything to the allowed identifier grammar.

I would just love to get out of the watch for and except loop that we always seem to be in.

I remember reading some where that dealing with nulls and exceptions therein is a lot like C and memory issues, and c++ has both dramas. I'm not overly C++ literate so I can't really comment.

In Ruby we tend to develop in a duck typing fashion, and since D is obviously statically typed, I'd love for the compiler to actually take care of some of the work for me, since it'll know anyways and i can delcare not wanting it.

Walter Bright wrote:
> Robby wrote:
>> Anyways, what I'm in hopes of finding is a way to tell the compiler that I never want null, ever. I want an instance of the class and that's that. The whole idea of taking every lil runtime hit for checking  and the code cruft for writing it when in fact it's something that seems to be easy for a compiler to do the work for me.
> 
> The hardware will do the check for null pointer for you every time you do a dereference.

Often, yes, but not always.  Presumably compilers are smart enough *not* to count on this for large offsets into objects and add explicit code when they guarantee to diagnose dereferences from null pointers. (But I'd check the generated code if I was going to rely on such a thing instead of ensuring that it didn't happen in the first place.)

-- James

On 12/8/07, Walter Bright <newshound1@digitalmars.com> wrote:
> The hardware will do the check for null pointer for you every time you do a dereference.

By which you mean, the program will crash. I don't see that as a good thing.

Walter Bright wrote:
> Robby wrote:
>> Anyways, what I'm in hopes of finding is a way to tell the compiler that I never want null, ever. I want an instance of the class and that's that. The whole idea of taking every lil runtime hit for checking  and the code cruft for writing it when in fact it's something that seems to be easy for a compiler to do the work for me.
> 
> The hardware will do the check for null pointer for you every time you do a dereference.

I wouldn't mind this. Only problem is, you don't get a file or line number. You don't get any clue where the problem is. You're left with debugging by printfs or attaching a debugger, and D doesn't have great debugger support at the moment. Either way takes much more time than simply reading an exception.

You might be able to trap SIGSEGV and output the last file and line number executed. The former's easy; the latter might require more upkeep than watching pointer dereferences.

Christopher Wright wrote:
> Walter Bright wrote:
>> Robby wrote:
>>> Anyways, what I'm in hopes of finding is a way to tell the compiler that I never want null, ever. I want an instance of the class and that's that. The whole idea of taking every lil runtime hit for checking  and the code cruft for writing it when in fact it's something that seems to be easy for a compiler to do the work for me.
>>
>> The hardware will do the check for null pointer for you every time you do a dereference.
> 
> I wouldn't mind this. Only problem is, you don't get a file or line number. You don't get any clue where the problem is. You're left with debugging by printfs or attaching a debugger, and D doesn't have great debugger support at the moment. Either way takes much more time than simply reading an exception.
> 
> You might be able to trap SIGSEGV and output the last file and line number executed. The former's easy; the latter might require more upkeep than watching pointer dereferences.

ddbg does a pretty decent job on Windows.  Still, it gives me no stack trace upon "access violation" a significant fraction of the time.  When it works it's great, though.  You should definitely be using it if you're on Windows.  I have also found that Windbg can sometimes get a stack trace when ddbg can't.

If you're not on Windows then I presume gdb works?  I guess that doesn't have any D-specific knowledge.  Support for D in zerobugs is still vaporware?

Still, I'm with you.  Getting a stack trace should be easier. Especially considering there have been patches to phobos floating around for a year at least that already implement it.

--bb