A couple of thoughts/queries.

[Robby]

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.