Why don't we try and be definitive about what needs to get done before a 1.0 release? Walter may contribute his list as well. (this is really what I'm looking for) <g>

Kyle Furlong wrote:

> Why don't we try and be definitive about what needs to get done before a 1.0 release? Walter may contribute his list as well. (this is really what I'm looking for) <g>

With the recent DMD 0.150 Release I think there are four things that need to be done before 1.0:

-Linux debugging symbols-- well... maybe not, but it needs to be there before I can really start hawking D  ;)

-Plaster all the documentation with recommendations to try Ares + Mango as an alternative to Phobos and instructions on how to do this. (I don't want to spark a debate on Mango vs Phobos, but I want Mango + Ares advertised as an option.)  In the final packaging, it might be a good idea to include some popular D packages such as Mango + Ares, and Derek's build. (Also DDL, once it's done)

-Linux shared object support

This one's the most important one:
-Anything with which Walter is not ABSOLUTELY satisfied with or believes to
be a hack MUST be dealt with before 1.0.  Now's your last chance to make
changes which could break code, Walter... the bit vs bool change is a good
example.

I think we're getting close, but maybe I'm just really happy about the new interface stuff.

~John Demme

John Demme wrote:
> Kyle Furlong wrote:
> 
> 
>>Why don't we try and be definitive about what needs to get done before a
>>1.0 release? Walter may contribute his list as well. (this is really what
>>I'm looking for) <g>
> 
> 
> 
> -Plaster all the documentation with recommendations to try Ares + Mango as
> an alternative to Phobos and instructions on how to do this. (I don't want
> to spark a debate on Mango vs Phobos, but I want Mango + Ares advertised as
> an option.)  In the final packaging, it might be a good idea to include
> some popular D packages such as Mango + Ares, and Derek's build. (Also DDL,
> once it's done)
> 

Full (or as much as doable) removal of runtime environment dependencys on Phobos.

> 
> This one's the most important one:
> -Anything with which Walter is not ABSOLUTELY satisfied with or believes to
> be a hack MUST be dealt with before 1.0.  Now's your last chance to make
> changes which could break code, Walter... the bit vs bool change is a good
> example.
> 
Ditto

> ~John Demme

BCS wrote:
> John Demme wrote:
>> Kyle Furlong wrote:
>>
>>
>>> Why don't we try and be definitive about what needs to get done before a
>>> 1.0 release? Walter may contribute his list as well. (this is really what
>>> I'm looking for) <g>
>>
>>
>>
>> -Plaster all the documentation with recommendations to try Ares + Mango as
>> an alternative to Phobos and instructions on how to do this. (I don't want
>> to spark a debate on Mango vs Phobos, but I want Mango + Ares advertised as
>> an option.)  In the final packaging, it might be a good idea to include
>> some popular D packages such as Mango + Ares, and Derek's build. (Also DDL,
>> once it's done)
>>
> 
> Full (or as much as doable) removal of runtime environment dependencys on Phobos.
> 

Do you realize what this entails? Many, I repeat *MANY* language *features* are implemented in phobos.
>>
>> This one's the most important one:
>> -Anything with which Walter is not ABSOLUTELY satisfied with or believes to
>> be a hack MUST be dealt with before 1.0.  Now's your last chance to make
>> changes which could break code, Walter... the bit vs bool change is a good
>> example.
>>
> Ditto
> 
>> ~John Demme

Kyle Furlong wrote:
> BCS wrote:
> 
>>
>> Full (or as much as doable) removal of runtime environment dependencys on Phobos.
>>
> 
> Do you realize what this entails? Many, I repeat *MANY* language *features* are implemented in phobos.
> 
a pipe dream?

How about full documentation on what is used, enough so that they can be replaced.

BCS wrote:
> Kyle Furlong wrote:
>> BCS wrote:
>>
>>>
>>> Full (or as much as doable) removal of runtime environment dependencys on Phobos.
>>>
>>
>> Do you realize what this entails? Many, I repeat *MANY* language *features* are implemented in phobos.
>>
> a pipe dream?
> 
> How about full documentation on what is used, enough so that they can be replaced.

Kyle Furlong wrote:
> Why don't we try and be definitive about what needs to get done before a 1.0 release? Walter may contribute his list as well. (this is really what I'm looking for) <g>

Not much more for the language, I reckon. Anything that will break code.
* AFAIK, the only new feature that needs to be done is the change to RAII syntax.
* Rounding out a few of the recent features, especially IFTI.
* Deprecate all undesirable features. I hope that this includes implicit declaration of printf, and reckless use of the comma operator.
* No bugs in bugzilla of 'normal' or higher severity.

(In practice, I'm now finding the biggest annoyance with the compiler is the way it dumps reams of incorrect error messages when it encounters a template any time after the first error).

Of course, the library's a different story...

Don Clugston wrote:
> (In practice, I'm now finding the biggest annoyance with the compiler is the way it dumps reams of incorrect error messages when it encounters a template any time after the first error).

Yes, that /does/ become tiresome rather quickly.

Another primary one to keep in mind is better debugger support (arrays, classes, etc)

Don Clugston wrote:
> Kyle Furlong wrote:
>> Why don't we try and be definitive about what needs to get done before a 1.0 release? Walter may contribute his list as well. (this is really what I'm looking for) <g>
> 
> Not much more for the language, I reckon. Anything that will break code.
> * AFAIK, the only new feature that needs to be done is the change to RAII syntax.
> * Rounding out a few of the recent features, especially IFTI.
> * Deprecate all undesirable features. I hope that this includes implicit declaration of printf, and reckless use of the comma operator.
> * No bugs in bugzilla of 'normal' or higher severity.
> 
> (In practice, I'm now finding the biggest annoyance with the compiler is the way it dumps reams of incorrect error messages when it encounters a template any time after the first error).
> 
> Of course, the library's a different story...

I think the template error thing will be a deal breaker for C++ template types. Heres a senario:

C++ guy reads about D v1.0 with cool new template system on /.

C++ guy gets D v1.0 compiler (without template error messages fixed)

C++ guy ports his sweet (so he thinks) template code to D

C++ guy compiles... and WTF?!?! REAMS OF OUTPUT, from a simple noobie error

C++ guy leaves D forever

Kyle Furlong wrote:

> Why don't we try and be definitive about what needs to get done before a 1.0 release? Walter may contribute his list as well. (this is really what I'm looking for) <g>

* 64 Bit support. That's a must. Or better: Arbitrary register length support. This of course means, that the ABI is built around the native length of pointers, pointer differences, etc.

Wishes for D v1.1:

* Eventually it may be good to have types like int8 int64 etc built into the language. In other languages (C/C++) this is done using a lot of ugly typedefs, or the compiler introduces types like __int8 which are then typedefed. Why not build this into the language? It won't break existing code, too (at least it doesn't "alias int int32; alias uint uint32;)"

* It would be great to have RTTI without the same dirty tricks as performed in C++ (deriving everything from a common CObject class, etc). Make RTTI Information avaliable by introducing static and dynamic properties.

* I'd like to have classes, interfaces and modules have
a .inferface property (eventually name it a bit different to
avoid clash with "normal" interfaces), that gives a data
structure describing all methods and properties of a class and
it's inheritance hierachy. The inheritance hierachy could be
exposed by a property .super which has itself an .interface
property and .super property. Just have a look at the dir(...)
command of the python language and you get the idea. This
capability of self description would make it much easier to
expose classes to foreign modules loaded by dynamic loaders or
being integrated into component systems or make it avaliable to
script interpreters. I think of the following:

import rtti; // get the types for RTTI

foreach(rtti.method method, this.methods)
{
        script_language_module.add_function(method.name, method.params);
}

method.params would be an array describing each parameter, eventually having a reference to other RTTI information again.

Up to today no language, that creates compiled binary code has this feature. Only .net managed code is the closest thing to have this, but it's not native but gets converted to native code by a JIT compiler at runtime.

* The other way would be cool, too, i.e. create a typed delegate from supplied method information. This delegate may then be used as callback or similair stuff. Through RTTI there is type safety and giving a mismatching delegate raises an exception. At the current state such delegates must be defined at compile time. Runtime function creation can be done with some dirty hacks, but still requires predefining the types. Normally this involves an associative array of an intermediary class that does the stack building and variadic functions. However this is not runtime safe. So such a class should be able to provide RTTI information.

* By the way .net: D is IMHO an ideal language to support .net. Eventually we should try to add CLI output to the compilers for it.

-- 
Wolfgang Draxinger