On 05/01/2012 12:53 AM, Andrej Mitrovic wrote:
> On 5/1/12, Timon Gehr<timon.gehr@gmx.ch>  wrote:
>> D2 ->  D3 will be full of breaking changes anyway.
>
> Uhmm I hope not,

Then what is the point of D3?

> otherwise D3 will be dead in the water.

Just provide an automatic D2->D3 conversion facility.

Timon Gehr:

> D2 -> D3 will be full of breaking changes anyway. Otherwise there is no reason to add another major language version.

I remember Walter (and Andrei) stated that D2 is the latest major breaking change in D. So D3 is supposed to be a smooth change (but of course no one knows what will happen).

Bye,
bearophile

Sorry for my 2nd intervention on this thread. I recently ported some (not much) code from C to D. My impression was that D(2) tries to be too many things at once. I even considered porting to D(1) instead of D(2). What attracted me into the first place to D was it promise to be a "better C" (and a better C++), at least this is I saw it. However, it seems to have grown too complex to me. Yes, I understand that new, modern features should be provided by the language, but I do not like to be forced to use those.

From my (limited) background, what I really liked in D:

*the new type[n] and type* declaration syntax
*the templates syntax (that's a biiig plus)
*other things that I do not remember now, but they are plenty of them
*the fact that constructors and destructors do not need renaming when class name changes (I hated that in C++ and Java), although I would have liked more special kewords like "ctor()" and "dtor()", instead of "this()" and "~this()", but I can cope with that)

What I did NOT like in D (is my impression):

*the confusion between . and -> operators (yes, I know the latter does not exist in D, is just for talking first here) for classes and structs and why classes are or are not pointers and why structs behave differently (or, at least, this is how I perceive it) and why not the pointer syntax is not used if they are pointers (well, references) and so on (yes, I am a bit dizzy, but is not entirely my fault; it's also D's).
*the many @ annotations that is not clear if they are compulsory or not (and, if not, how to convince me to use them...)
*the writing of the p[0..len] that you need to use when some other code (C code) passes you the pointer to data and the length (I just do not like it)
*it is also my impression that you cannot declare int[] x=<<some_initialization>> as a static array with length filled in by compiler at the compile time, since the length is known? instead, x is interpreted as a dynamic array (which, also, I do not like that same syntax, or very similar, is used for both concepts).
*the fact that the calling of a function bears no indication if you modify or not the passed variable (I much prefer the C-ish style of foo(a,&b); where you *almost* know that b will be modified)

Well, these are some. I feel that the right line is somewhere between D1 and D2. It is good that advanced, complex features are present in D, I just not want to be forced to use those when porting "traditional" C code.

I expected to meet D and exclaim: wow! C++ done right! Instead, I feel like being forced to learn another, completely new paradigm language, like I would start with Lisp or something else.

Remember:
"Within D, there is a much smaller and cleaner language struggling to get out".

On 05/01/2012 12:54 AM, Kapps wrote:
> On Monday, 30 April 2012 at 19:50:36 UTC, Walter Bright wrote:
>>
>> I'm surprised nobody has mentioned opApply. That was a good idea at
>> the time, but Ranges are a superior solution. I'd like to see new code
>> not use opApply. It's a dead end, though it'll still be supported for
>> a long time.
>
> I practically never use ranges, and instead use opApply for all my code.
>
> 1) Ranges force me to use a specific naming convention. My naming
> convention that I use for my projects is upper camel case. Ranges do not
> allow this.

Yes they do. (If you are willing to have both kinds of symbols around.)

mixin template AddAliasesForBuiltInRange(){
    alias Front front;
    alias Empty empty;
    alias PopFront popFront;
}

struct R{
    ...
    @property Front(){...}
    @property bool Empty(){...}
    void PopFront(){...}

    mixin AddAliasesForBuiltInRange;
}


> Technically opApply is still lower camel case, but my code
> doesn't directly call it.
>

The same would hold for the above example.

> 2) Ranges don't have a way of determining when the iteration ends.
> Sometimes you want to do something once iteration stops. For example, by
> far the most common action when executing a database call for me, is to
> iterate over it and close it. I can then have a helper method that
> executes the command and closes it when the foreach is done (whether by
> break or by the function ending). This saves quite a bit of boiler plate
> code.
>

An important point.

> 3) Ranges can be difficult to implement. You now have to keep track of
> state instead of simply leaving everything inside a single method call.
> This can also cause significant problems with multi-threaded code.
>
> 4) Ranges take a lot more code, which when all you want is basic
> iteration, is pointless to have
>

Those two could be mitigated by moving the range concept further into the language.

> I'd much rather just see things with opApply being able to have a
> forward-range magically created for it, much like the reverse. Not sure
> if this is possible or practical though.
>

Am implementation (that is possible now) could use coroutines (core.thread.Fiber), but that is not very efficient for simple iteration. Compiler support would be a solution. See eg. C# yield return. (In D the compiler would generate anonymous struct types instead of IEnumerable interface implementations).

Kapps:

> 1) Ranges force me to use a specific naming convention. My naming convention that I use for my projects is upper camel case. Ranges do not allow this.

Not following the common naming conventions of a language is bad, or quite bad. Most or all modern languages seem to have realized this (Ruby, Python, C#, Go, Scala, and probably several others).

When I see D code written by other people it's very handy to guess some characteristics of the things I'm using assuming it follows the D common naming conventions. This makes reading code simpler, faster, reduces some chances of introducing bugs, and makes is quicker to hack into code written by other people.

Bye,
bearophile

On 5/1/12, Timon Gehr <timon.gehr@gmx.ch> wrote:
> On 05/01/2012 12:53 AM, Andrej Mitrovic wrote:
>> On 5/1/12, Timon Gehr<timon.gehr@gmx.ch>  wrote:
>>> D2 ->  D3 will be full of breaking changes anyway.
>>
>> Uhmm I hope not,
>
> Then what is the point of D3?

An incremental improvement with as little code breakage as possible? You can't even properly mix D1 and D2 code in the same library right now without resorting to using mixin() tricks.

akaz:

> Well, these are some. I feel that the right line is somewhere between D1 and D2. It is good that advanced, complex features are present in D, I just not want to be forced to use those when porting "traditional" C code.
>
> I expected to meet D and exclaim: wow! C++ done right! Instead, I feel like being forced to learn another, completely new paradigm language, like I would start with Lisp or something else.

I think D is not C++ done right any more, it's a new language. This was probably necessary if you want D to have a more than minimal chance of success.

I have translated a significant amount of C code to D1 and D2, and usually in such simple porting I find bugs in the original C code, like off-by-on errors in arrays, missing returns, missing breaks in switches, dead code paths caused by precedent returns, erroneous re-uses of loop variables used in outer scopes, and so on. So I love such (moderate) bug-discovering qualities of D, and I'd like D to have even more of them.

In many cases D doesn't force you to use its advanced features, it allows you to write very C-looking code too (that is usually bad D code). But probably D can't allow this in every case, some things need to change if you want to improve the language a little. So think of those forced uses as a small price to pay to have a better language.

Bye,
bearophile

On 05/01/2012 01:20 AM, akaz wrote:
>
> I expected to meet D and exclaim: wow! C++ done right! Instead, I feel
> like being forced to learn another,

Yes, D is its own thing.

> completely new paradigm language,
> like I would start with Lisp or something else.
>

OTOH, this seems to be an exaggeration.

> Remember:
> "Within D, there is a much smaller and cleaner language struggling to
> get out".
>


I don't see the value of that assertion from a pragmatic point of view.

What is to be gained? Note that you have discussed mostly syntax.


* adding -> does not make the language smaller or cleaner and it
  complicates generic code for no benefit.

* loosening the syntactic distinction between value and reference type
  variable declarations could be done, (to the neat effect that
  tail-qualified class references would trivially work) but there
  shouldn't be any directly built-in support for treating polymorphic
  class instances as values.

* I agree that the @property situation needs to be cleaned up. There
  are only five @annotations in total. And what you have said does not
  apply to the other four.

* how p[0..len] can be seen as an issue instead of as great completely
  escapes my mind.

* I agree on supporting deducing length for static arrays. (there is a
  int[$] arr = [1,2,3]; proposal.)

* the syntax for arrays is straightforward and I don't see any
  potential for improvement.

* the foo(a,&b) example is biased because it uses a meaningless
  function name. From the function name alone it is often *almost*
  clear that a certain argument will be modified. & & & spam is not
  'clean' either.

Timon Gehr:

> * I agree on supporting deducing length for static arrays. (there is a
>   int[$] arr = [1,2,3]; proposal.)

Someone in Bugzilla ha just proposed an alternative idea, that despite not looking very nice, is not overall bad (here with a small change):

auto arr = [1, 2, 3]f;

That trailing f denotes a fixed-side array/string literal. So it's usable for other situations too.


> * the foo(a,&b) example is biased because it uses a meaningless
>   function name. From the function name alone it is often *almost*
>   clear that a certain argument will be modified. & & & spam is not
>   'clean' either.

In C# you need to use "ref" and "out" at the calling point (in most cases). D language has chosen a different design, but here C# design has some advantages too, it makes the code semantics a bit more clear.

Bye,
bearophile

On Tue, 01 May 2012 01:20:53 +0200, akaz <nemo@utopia.com> wrote:

> *the confusion between . and -> operators (yes, I know the latter does not exist in D, is just for talking first here) for classes and structs and why classes are or are not pointers and why structs behave differently (or, at least, this is how I perceive it) and why not the pointer syntax is not used if they are pointers (well, references) and so on (yes, I am a bit dizzy, but is not entirely my fault; it's also D's).

Really? This is one of the big pluses to me.


> *the writing of the p[0..len] that you need to use when some other code (C code) passes you the pointer to data and the length (I just do not like it)

While I can agree it's not perfect, I have a hard time seeing a better
solution. Somewhere the information has to be combined to create a proper
array.


> *it is also my impression that you cannot declare int[] x=<<some_initialization>> as a static array with length filled in by compiler at the compile time, since the length is known? instead, x is interpreted as a dynamic array (which, also, I do not like that same syntax, or very similar, is used for both concepts).

Agreed.



> *the fact that the calling of a function bears no indication if you modify or not the passed variable (I much prefer the C-ish style of foo(a,&b); where you *almost* know that b will be modified)

Yeah. C# truly got this right with its enforcement of marking passed
parameters ref or out. I'd really like that for D too.