Walter!

I have been following the evolution of D for at least five years.
Nowadays all of my personal projects are written in D. No exception.
Seeing D 1.00 was great in January. After it 1.013 (maybe 014) with struct literals was the last thing I ever needed from D.

BUT: This 2.000 and it's 'features' looks like your are joking. Stop it! Bullshit! Const string is the worst thing I ever heard.

D is great dealing char arrays, slicing, COW and soon. Let it so.

If you have no idea what to do, please wait! No need to hurry!

D do not have to copy bad ideas from Java and C#!
MicroShit developers WILL NOT use D even it supports const.

I do not want to hurt You, Walter or anyone reading this news.
I only want to warn the community. This is a mistake. Bad direction.

Regards,
Tamás Nagy
Hungary


Walter Bright Wrote:

> This is an alpha release to try out the const/final/invariant stuff.
> 
> The current definition of string is:
> 
> 	alias const(char)[] string;
> 
> Andrei has argued strongly to make it invariant. I think he's probably right, and that change might happen next.
> 
> The documentation isn't thorough, I don't want to spend too much time on it until I'm sure we've got the design right.
> 
> Treat this as an alpha release. Although it passes its test suite, I'm sure there are plenty of bugs remaining. Phobos also has not been thoroughly gone through to put const/final in all the right places.
> 
> See http://www.digitalmars.com/d/final-const-invariant.html
> 
> http://www.digitalmars.com/d/changelog.html
> 
> http://ftp.digitalmars.com/dmd.2.000.zip
> 
> Expect changes to this. Much more to come! For stability, I recommend sticking with the 1.0 series, which I will maintain with bug fixes.

MicroWizard Wrote:

> BUT: This 2.000 and it's 'features' looks like your are joking. Stop it! Bullshit! Const string is the worst thing I ever heard.

Harsh words.
If you don't bring forward arguments,
your post will most likely be ignored.

MicroWizard wrote:
> Walter!
> 
> I have been following the evolution of D for at least five years.
> Nowadays all of my personal projects are written in D. No exception.
> Seeing D 1.00 was great in January. After it 1.013 (maybe 014) with struct literals was the last thing I ever needed from D.
> 
> BUT: This 2.000 and it's 'features' looks like your are joking.
> Stop it! Bullshit! Const string is the worst thing I ever heard.
> 
> D is great dealing char arrays, slicing, COW and soon. Let it so.
> 
> If you have no idea what to do, please wait! No need to hurry!
> 
> D do not have to copy bad ideas from Java and C#!
> MicroShit developers WILL NOT use D even it supports const.
> 
> I do not want to hurt You, Walter or anyone reading this news.
> I only want to warn the community. This is a mistake. Bad direction.
> 
> Regards,
> Tamás Nagy
> Hungary
> 

You are kidding, right?  I've been specifically sitting on all my projects, twiddling my thumbs, just waiting /for/ the new final|const|invariant!  Now I'm just waiting for Tango to go D/2.0 and I can get down to serious work again (finally).  This is going to save me plenty of memory costs (imagine, no longer .dup'ing lots of strings and other arrays just to play it safe against silly end users modifying what they shouldn't) not to mention debugging headaches.

Yes... clearly you must be kidding.

-- Chris Nicholson-Sauls

It is already ignored in my case, because this guy obviously did not follow thorogh discussion about matters he criticizes...

On Wed, 20 Jun 2007 01:25:23 +0400, Chris Nicholson-Sauls <ibisbasenji@gmail.com> wrote:

> I've been specifically sitting on all my projects, twiddling my thumbs, just waiting /for/ the new final|const|invariant!  Now I'm just waiting for Tango to go D/2.0 and I can get down to serious work again (finally).

<old-talk>
Some time ago I waited for D 1.0. Now I'm awaiting D 2.0. Then, I'm afraid, I would wait for next major stable version of D. There ins't any sign that after almost seven years of development D will became stable and mature language.

Excuse me for repeating that.
</old-talk>

> This is going to save me plenty of memory costs (imagine, no longer .dup'ing lots of strings and other arrays just to play it safe against silly end users modifying what they shouldn't) not to mention debugging headaches.

How do you plain to reduce count of .dup's in D 2.0?

-- 
Regards,
Yauheni Akhotnikau

eao197 wrote:
> <old-talk>
> Some time ago I waited for D 1.0. Now I'm awaiting D 2.0. Then, I'm
> afraid, I would wait for next major stable version of D. There ins't any
> sign that after almost seven years of development D will became stable
> and mature language.
> 
> Excuse me for repeating that.
> </old-talk>

So use D 1.0--it's stable now!  As Walter has said, it's just going to be maintained with bugfixes now, no more moving target.

If your argument is "I can't use D 1.0 because D 2.0 exists", then I suspect you won't be happy until D has ceased all evolution and updates, effectively dying, at which point you'll probably start using a different, shinier language.

Sometimes you've just got to draw a line in the sand and not step across it.  The game I'm currently writing will, despite how much I want to use D 2.0, be written in D 1.0 because it's now a fixed target, and has libraries and tools working with it.  Yes, it's tearing me up inside not having shiny new const, but getting the game written and working is more important to me right now.

>> This is going to save me plenty of memory costs (imagine, no longer .dup'ing lots of strings and other arrays just to play it safe against silly end users modifying what they shouldn't) not to mention debugging headaches.
> 
> How do you plain to reduce count of .dup's in D 2.0?

I believe what Chris is talking about is that if you want an array (or any other reference type, for that matter) that is absolutely guaranteed not to change on you, you currently need to .dup the whole thing every single time.

With D 2.0, it will be possible to overload functions to accept an invariant reference, which we don't need to dup, making the code more efficient.

	-- Daniel

eao197 wrote:
> On Wed, 20 Jun 2007 01:25:23 +0400, Chris Nicholson-Sauls <ibisbasenji@gmail.com> wrote:
> 
>> I've been specifically sitting on all my projects, twiddling my thumbs, just waiting /for/ the new final|const|invariant!  Now I'm just waiting for Tango to go D/2.0 and I can get down to serious work again (finally).
> 
> <old-talk>
> Some time ago I waited for D 1.0. Now I'm awaiting D 2.0. Then, I'm afraid, I would wait for next major stable version of D. There ins't any sign that after almost seven years of development D will became stable and mature language.
> 
> Excuse me for repeating that.
> </old-talk>

You are excused, especially since I've played the same waiting game (indeed).  That said, I'm probably going to just ride the 2.0 branch at this point and be happy.  I'll refactor if and when anything just-too-nifty comes along.

>> This is going to save me plenty of memory costs (imagine, no longer .dup'ing lots of strings and other arrays just to play it safe against silly end users modifying what they shouldn't) not to mention debugging headaches.
> 
> How do you plain to reduce count of .dup's in D 2.0?
> 

By returning const views rather than copies.  Or in some cases, referances to invariant data.

-- Chris Nicholson-Sauls

On Wed, 20 Jun 2007 17:39:43 +0400, Chris Nicholson-Sauls <ibisbasenji@gmail.com> wrote:

>>> This is going to save me plenty of memory costs (imagine, no longer .dup'ing lots of strings and other arrays just to play it safe against silly end users modifying what they shouldn't) not to mention debugging headaches.
>>  How do you plain to reduce count of .dup's in D 2.0?
>>
>
> By returning const views rather than copies.  Or in some cases, referances to invariant data.

Do you mean something like:

class Demo
  {
    this( const char * name )
      {
        name_ = name.dup;
      }

    const char *
    getName() { return name_; }

  private:
    char[] name_;
  }

instead of

  char[]
  getName() { return name_.dup; }

?

-- 
Regards,
Yauheni Akhotnikau

On Wed, 20 Jun 2007 14:19:47 +0400, Daniel Keep <daniel.keep.lists@gmail.com> wrote:

> eao197 wrote:
>> <old-talk>
>> Some time ago I waited for D 1.0. Now I'm awaiting D 2.0. Then, I'm
>> afraid, I would wait for next major stable version of D. There ins't any
>> sign that after almost seven years of development D will became stable
>> and mature language.
>>
>> Excuse me for repeating that.
>> </old-talk>
>
> So use D 1.0--it's stable now!  As Walter has said, it's just going to
> be maintained with bugfixes now, no more moving target.
>
> If your argument is "I can't use D 1.0 because D 2.0 exists", then I
> suspect you won't be happy until D has ceased all evolution and updates,
> effectively dying, at which point you'll probably start using a
> different, shinier language.

It is not easy to me to start use different language because I have big enough rather old code which I should maintain and advance. At best I will be able to maintain old C++ code and write new code in D.

<old-talk-again>
In my option the problem with branching D into 1.0 and 2.0 not in language. The problem in the libraries, tools, documetation and people around D.

For example, now D is attracting new people. Someone want to write new tools/libraries for D. Which version will they choose? Stable, but old, D 1.0 or unstable, but very promising and attractive D 2.0? I'm affraid many of them choose D 2.0 (because I would do that). And because of that in time D 2.0 would have more tools/libraries than D 1.0.

The same thing with documentation. The same thing with teaching people to program in D. Even worse. Designing programs without consts/invariants is much different than designing programs with consts/invariants. So why to spend time to teaching new programmers to use old-style D instead of teaching them new-style D?

I like to see consts/invariants in D. But... Implantaion of D as main programming language (instead of C++, like in my case) in industry needs a lot of efforts to re-teaching people, creating some proof-of-concent projects, defining some corporate politics and best practices. Even in the best conditions it may took months, may be years. Why to make thing ever worse with language which is always in beta-stage?

I need to remember that in addition to early adopters (like you, Daniel) and technologist (like I) there are many, many rather conservative, pessimistic and simply lazy programmers who don't want to study something new every month or even a half-year. But they do much, much work. Please keep them in mind.

Excuse me for repeating that yet more time.
</old-talk-again>

-- 
Regards,
Yauheni Akhotnikau

eao197 wrote:
> On Wed, 20 Jun 2007 17:39:43 +0400, Chris Nicholson-Sauls <ibisbasenji@gmail.com> wrote:
> 
>>>> This is going to save me plenty of memory costs (imagine, no longer .dup'ing lots of strings and other arrays just to play it safe against silly end users modifying what they shouldn't) not to mention debugging headaches.
>>>  How do you plain to reduce count of .dup's in D 2.0?
>>>
>>
>> By returning const views rather than copies.  Or in some cases, referances to invariant data.
> 
> Do you mean something like:
> 
> class Demo
>   {
>     this( const char * name )
>       {
>         name_ = name.dup;
>       }
> 
>     const char *
>     getName() { return name_; }
> 
>   private:
>     char[] name_;
>   }
> 
> instead of
> 
>   char[]
>   getName() { return name_.dup; }
> 
> ?
> 

Rough draft off the top of my head, working from an actual project:

# module bovis .types .Symbol ;
#
# // includes: alias char[] BString
# private import bovis .types .Basic ;
#
# public final class BSymbol {
#
#   private static BSymbol[invariant BString] p_pool ;
#
#   public static BSymbol opIndex (BString str) {
#     BSymbol result ;
#
#     if (auto ptr = str in p_pool) {
#       result = *ptr;
#     }
#     else {
#       result = new BSymbol(str);
#       p_pool[str.idup] = result;
#     }
#     return result;
#   }
#
#   private invariant(BString) m_str ;
#
#   private this (BString str) {
#     m_str = str.idup ;
#   }
#
#   public invariant(BString) string () {
#     return m_str ;
#   }
#
# }

Usage:
auto alpha = BSymbol["test"] ;
auto beta  = BSymbol["test"] ;
assert(alpha is beta);

(The use of this isn't obvious I know.  Just trust me that it has great utility in the program its part of.)

Now first, yes, there are two .idup's in there.  I'm not sure if they're neccessary or not, and haven't tested things yet.  But... in the original, there are /three/ .dup's.  I can now do away with the one in .string(), which is the one I'm most worried about, since the duplicate it would've created is short-lived.  (The other two are very long-lived; life of the program, in theory.)  Thus, having those 'invariant's in there lets me avoid a myriad of needless copies -- I can just copy it on the user side if I need to, most likley happening automatically as part of a concatenation.

Now I just need to a chance to test this to see if it all works in the way my head seems to have it organized.

-- Chris Nicholson-Sauls