Among the many as-yet-unfulfilled prerequisites for being ready for 1.0 is coming to a final decision on the feature set.

On releasing 0.93, Walter stated:

"Barring a very, very, compelling case, this is it for 1.0 language features.  There are a lot more things I want to do, but this has got to be enough for 1.0."

However, there have been lots of new features since then.  And as new features are added, it opens the door to more bugs and more imperfections in the spec.

I think that sometime soon, we should finally make it more firm that "this is it for 1.0 language features".  Once this is done, then we can finally concentrate more on fixing compiler bugs and getting the spec up to scratch (both cleaning up spelling/grammar and cleaning up what is ill-defined) without having to worry too much about creating even more work for ourselves in the process.

Stewart.

Stewart Gordon wrote:
> I think that sometime soon, we should finally make it more firm that "this is it for 1.0 language features".  Once this is done, then we can finally concentrate more on fixing compiler bugs and getting the spec up to scratch (both cleaning up spelling/grammar and cleaning up what is ill-defined) without having to worry too much about creating even more work for ourselves in the process.

The only thing I can think off that should be fixed before 1.0 is the "auto" keyword.

It's current double meaning is a mess, and it needs to be defined as either a RAII or a type deduction keyword (and another keyword/syntax needs to be introduced for the other meaning.)

I'm leaning towards making "auto" mean type deduction, and introduce another keyword ("raii"? Unlikely to break old code, I'd venture) for RAII allocations.

That'd be a change from the C meaning of "auto", but so is the D meaning of "typedef" (since C's "typedef" is D's "alias"), and "auto" is practically never used in C, even.

Søren J. Løvborg
web@kwi.dk

Søren J. Løvborg skrev:
> Stewart Gordon wrote:
>> I think that sometime soon, we should finally make it more firm that "this is it for 1.0 language features".  Once this is done, then we can finally concentrate more on fixing compiler bugs and getting the spec up to scratch (both cleaning up spelling/grammar and cleaning up what is ill-defined) without having to worry too much about creating even more work for ourselves in the process.
> 
> The only thing I can think off that should be fixed before 1.0 is the "auto" keyword.
> 
I can also think of allowing properties as lvalue:
foo.bar += 42;

Array literals:
bar ~= [1,5,42];

Struct literals:
baz = {"hej", 42};


Those and the lack of sets and ranges are top on my list. The small stuff that can reduce code size in half. The only 100% foolproof way to write bug-free code is; not to write any. So the closer to no code, the better :).


// Fredrik Olsson

Fredrik Olsson wrote:
<snip>
> I can also think of allowing properties as lvalue:
> foo.bar += 42;
> 
> Array literals:
> bar ~= [1,5,42];

The problem with that notation is that, in the general case, the type of the array cannot be guaranteed.  There have been a number of proposed syntaxes; AFAIK the best so far is

http://www.digitalmars.com/d/archives/digitalmars/D/39125.html

So your answer to the subject of this thread is "Once these features have been added", right?  Could be a long time.... :-)

<snip>
> Those and the lack of sets and ranges are top on my list. The small stuff that can reduce code size in half. The only 100% foolproof way to write bug-free code is; not to write any. So the closer to no code, the better :).

How does not writing code equate to writing code?

But you remind me of this:

http://www.stevemcconnell.com/cctune.htm

(See from "A fast program is just as important as a correct one--False!" downwards.)

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:-@ C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

Stewart Gordon wrote:
> Fredrik Olsson wrote:
> <snip>
>> I can also think of allowing properties as lvalue:
>> foo.bar += 42;
>>
>> Array literals:
>> bar ~= [1,5,42];
> 
> The problem with that notation is that, in the general case, the type of the array cannot be guaranteed.  There have been a number of proposed syntaxes; AFAIK the best so far is
> 
> http://www.digitalmars.com/d/archives/digitalmars/D/39125.html

I agree! That is the best proposal so far. I know Walter wants that to be a 2.0 feature but it still doesn't make sense to me.
Array and struct initializers are more fundamental feature than templates, delegates, lazyness, even classes, and they are going to be missing from D1.0? Crazy!

These days each D project I start has
T[] array(T)(T[] x...)
{
   return x.dup;
}

right after the module statement and that should be an indication that something is wrong. Although the array template fixes (kind of) the array initialization problem, there is nothing that can be done for structs (not counting static opCall as a solution).

Ivan Senji wrote:
> Stewart Gordon wrote:
>> Fredrik Olsson wrote:
>> <snip>
>>> I can also think of allowing properties as lvalue:
>>> foo.bar += 42;
>>>
>>> Array literals:
>>> bar ~= [1,5,42];
>>
>> The problem with that notation is that, in the general case, the type of the array cannot be guaranteed.  There have been a number of proposed syntaxes; AFAIK the best so far is
>>
>> http://www.digitalmars.com/d/archives/digitalmars/D/39125.html
> 
> I agree! That is the best proposal so far. I know Walter wants that to be a 2.0 feature but it still doesn't make sense to me.
> Array and struct initializers are more fundamental feature than templates, delegates, lazyness, even classes, and they are going to be missing from D1.0? Crazy!

Those things would delay D1.0 by months. The idea is to declare D1.0 quickly, and then move onto those things.

Don Clugston wrote:
> Ivan Senji wrote:
>> Stewart Gordon wrote:
>>> http://www.digitalmars.com/d/archives/digitalmars/D/39125.html
>>
>> I agree! That is the best proposal so far. I know Walter wants that to be a 2.0 feature but it still doesn't make sense to me.
>> Array and struct initializers are more fundamental feature than templates, delegates, lazyness, even classes, and they are going to be missing from D1.0? Crazy!
> 
> Those things would delay D1.0 by months. The idea is to declare D1.0 quickly, and then move onto those things.

I know, and I wouldn't like that to happen but many other features have been delaying D for years (not saying that I don't like them).

I don't have anything against D1.1 od D1.5 or even D2.0 having these features but I am a little worried about what happens when D1.0 attracts  new people and they must very quickly realize "what? D doesn't have array and struct literals? What kind of a language is that?"

Is that kind of negative publicity bad or not I don't know but it might make D feel incomplete. When you stay around D for a while you realize it isn't that incomplete after all but for some people the first negative impression is going to be the last impression they make of D.

* Ivan Senji:
> I don't have anything against D1.1 od D1.5 or even D2.0 having these features but I am a little worried about what happens when D1.0 attracts new people and they must very quickly realize "what? D doesn't have array and struct literals? What kind of a language is that?"

I'm more concerning about memory management scheme.

Most people I was talking to about D (and I agitate very fellow programmer i personally know to at least try D)... firstly complains about 'yet another language' syndrome. There is really nothing can be done about it, you just have to convince them to not to stop discussion =)

Next, everyone from C/C++ camp (especially C) is just so-skeptical about GC. All sort of things were already beaten to death here on NG. It is a meter of personal taste and there is nothing can't be done either.

And then usually happens following: on my clumsy allegations that it is not necessary to use GC, and with malloc/free one could manage memory manually. Well, you know... Whom I trying to deceive, myself? It is simply not so convenient to actually do so. And what about string operations (concatenations, assignment etc), they use GC and i don't know how to avoid it. Plus, standard library is hard-coupled with GC. My point is that if not use GC programming with D is even more awkward then C/C++.

But that not worst part. Although I'm personally from C++ camp and I get used to GC. and see it as good thing. But, there is one big BUT! Currently GC do not return memory to OS, and that thing even I can't subdue. The only reason I choose 'native' (as opposite to VM) programming language is effective resource usage. I hate Java/.net gui applications because their memory consuming. I really appreciate developers that choose c/c++ to write small, memory effective, but yet feature-reach applications like FileZilla Server, uTorrent or Miranda IM.

Most desktop applications (like text editors, news readers, web browsers, etc) must coexist with each other. That is, to use memory wisely and give it back if it not needed anymore. This 'upper water mark' approach in GC is just not acceptable.

All I actually can say to my fellow programmers in defense of D, is that language still developing and eventually all good things happens. On that point discussion usually ends and the bottom line is "nice language, we will look at later, when/if it evolve".

And for GC, to fee memory back to OS is crucial to every one who care about memory management. And ones who do not - whey will stay with their Java/.net VM monsters and will newer even look at D. Besides, this type of developers do not care about anything but their CV. Sure thing D will not help them.


P.S. sorry for rather long post. I don't expect it myself to be so =)
-- 
serg.

Serg Kovrov wrote:
> * Ivan Senji:
>> I don't have anything against D1.1 od D1.5 or even D2.0 having these features but I am a little worried about what happens when D1.0 attracts new people and they must very quickly realize "what? D doesn't have array and struct literals? What kind of a language is that?"
> 
> I'm more concerning about memory management scheme.
> 
> Most people I was talking to about D (and I agitate very fellow programmer i personally know to at least try D)... firstly complains about 'yet another language' syndrome. There is really nothing can be done about it, you just have to convince them to not to stop discussion =)
> 
> Next, everyone from C/C++ camp (especially C) is just so-skeptical about GC. All sort of things were already beaten to death here on NG. It is a meter of personal taste and there is nothing can't be done either.
> 
> And then usually happens following: on my clumsy allegations that it is not necessary to use GC, and with malloc/free one could manage memory manually. Well, you know... Whom I trying to deceive, myself? It is simply not so convenient to actually do so. And what about string operations (concatenations, assignment etc), they use GC and i don't know how to avoid it.

The same as you would in C.  Manually allocate and free the buffer referenced by the array ptr.  The layout of dynamic arrays is specified in the ABI, so you're guaranteed to have a .len and .ptr property to play with if you really want to.

> Plus, standard library is hard-coupled with GC.

It doesn't have to be.  That's just how Phobos was written.

> My
> point is that if not use GC programming with D is even more awkward then C/C++.

True.  Though I think 'scope' statements help a lot, and stack allocation will help tremendously.  Walter has already said he plans to implement:

  MyClass c = new MyClass(); // heap alloc
  MyClass d = MyClass();     // stack alloc

And hopefully:

  char[] a = new char[32]; // heap alloc
  char[] b = char[32];     // stack alloc

This would do away with the need for alloca(), which would conflict with dynamic closures anyway.  An in-language solution, however, may be compatible in some cases.

> But that not worst part. Although I'm personally from C++ camp and I get used to GC. and see it as good thing. But, there is one big BUT! Currently GC do not return memory to OS, and that thing even I can't subdue.

This is just the default GC shipped with DMD (and GDC).  There's no reason it can't be replaced.  In fact, I've taken steps to make this as easy as possible in Ares.

> Most desktop applications (like text editors, news readers, web browsers, etc) must coexist with each other. That is, to use memory wisely and give it back if it not needed anymore. This 'upper water mark' approach in GC is just not acceptable.

I think it depends on the application.  If an application behaves consistently across their run cycle, there's no reason to return memory to the OS because it will likely be needed again.  If an application allocates a ton of memory, frees it, and never uses it again then what you say is true.  Though in these cases the application could call malloc/free for these one-time memory allocations as well.

> All I actually can say to my fellow programmers in defense of D, is that language still developing and eventually all good things happens. On that point discussion usually ends and the bottom line is "nice language, we will look at later, when/if it evolve".

I think it's important to separate discussions of the language with the behavior of accompanying library code.  The GC occupies kind of a strange middle-ground here, but I still consider it library code because nothing inside is required to be compiler-specific.  Sure the compiler runtime allocates and frees memory, but it doesn't need special access that is not available to the user.  Personally, I think D as a language is shaping up quite nicely.  The library could perhaps use a little work, but that can be done without changing the language spec.


Sean

Sean Kelly wrote:
> Serg Kovrov wrote:
>> Most desktop applications (like text editors, news readers, web browsers, etc) must coexist with each other. That is, to use memory wisely and give it back if it not needed anymore. This 'upper water mark' approach in GC is just not acceptable.
> 
> I think it depends on the application.  If an application behaves consistently across their run cycle, there's no reason to return memory to the OS because it will likely be needed again.  If an application allocates a ton of memory, frees it, and never uses it again then what you say is true.  Though in these cases the application could call malloc/free for these one-time memory allocations as well.

I can't imagine an application that shouldn't free (return to OS) memory in runtime. Perhaps only really 'heavy' monopoly applications (like games, 3d modeling packages) and 'run and die' tools (like grep, less).

Other application that possibly could running unlimited time and process some significant amount of data, simply MUST return unused memory to OS.

For example web browser - user could open up to several tens of web pages simultaneously. Some maybe enormously big. If browser will no free memory consumed in such peak moments use will be forced to restart application (e.g. experience inconveniences) or will experience slowdown caused by swapping.

Same goes to any application working with arbitrary-sized data - image viewers, mail notificators, IDEs or text publishing tools, p2p clients or servers... Rally. As user, I don't want my everyday applications to hold peak memory, or restart them constantly. In the end i will chose other software, that will satisfy my habits.

I found it silly to shape behavior of an application by language (or it standard library) limitations.

If only programmer could have some control over GC, it would be just fine. For example to query GC's memory pool and decide to free some amount if it exceed some threshold. Walter, any comments on this?

-- 
serg.