On 29-04-2012 00:18, Manu wrote:
> On 28 April 2012 21:47, Walter Bright <newshound2@digitalmars.com
> <mailto:newshound2@digitalmars.com>> wrote:
>
>     Andrei and I had a fun discussion last night about this question.
>     The idea was which features in D are redundant and/or do not add
>     significant value?
>
>     A couple already agreed upon ones are typedef and the cfloat,
>     cdouble and creal types.
>
>     What's your list?
>
>
> I personally find the wealth of features in D to be one of it's major
> selling points. It helps simplify user code a lot, but I think there is
> room for some things to be more consistent:
>
> * version refuses to allow boolean logic, I need boolean logic, thus
> version is redundant to me. I find myself using static if almost
> exclusively in its place. I like the *idea*, but it's un-usably limited.

+1.

> * Consolidation of meta/introspection: __traits(), std.traits, is(), and
> a few other tricks, I often don't know where I should look to perform a
> particular introspection task. __traits is unsightly, it looks more like
> a hack rather than a feature, but it fills perhaps one of the most vital
> roles in the language.
> * D has a lot of attributes, many of which I haven't used + don't
> understand. I suspect many of them could be removed and implemented in
> the library with a proper user attribute system (which would be really
> useful to compliment D's introspection anyway). This would also free
> those keywords when those libraries aren't imported/used.
> * I don't know the value of AA's in the language, I've only used them
> once or twice. Because AA's can be implemented in numerous ways (map,
> hash table, etc), and may be ordered or unordered, the the choice of
> which to use is actually important to the problem more often than not.
> As long as the same convenience can be achieved in the library (literal
> expression?), maybe it should be there.


-- 
- Alex

On 29-04-2012 03:06, bearophile wrote:
> Jonathan M Davis:
>
>> * foreach_reverse is essentially redudant at this point (not to mention
>> confusing if combined with delegates), since we have retro.
>
> retro() can't replace foreach_reverse until the front-end
> demonstrability produces asm code equally efficient.
> Loops _must_ be fully efficient, they are a basic language construct,
> this is very important. Even foreach() is sometimes not equally
> efficient as a for() in some cases...
>
>
>> * I hate C style struct initializers and would really like to see them
>> go, but
>> for reasons that I don't understand, people actually use them rather
>> than using a proper constructor call,
>
> For single structs I prefer D-style initialization.
> But take a look at this code, if you replace those C-style initializers
> with D-style, even using aliases to shorten the code to single letters,
> that data section becomes more noisy:
> http://rosettacode.org/wiki/Ray-casting_algorithm#D
>
>
>> * As for features that add little value, the first one that comes to
>> mind is
>> with. I think that I've used it all of once, and I don't think that
>> I've seen
>> it in other people's code very often.
>
> It's rather common in Pascal/Delphi programming. I use it now and then.
>
> For a case where it's very handy see here, with an enumeration:
> http://rosettacode.org/wiki/Stable_marriage_problem#Alternative_version
>
>
>> It's hard to grep for (since with is
>> used in comments quite often),
>
> Try to search for "with(" or "with\s(", that are less common in normal
> text.
>
>
>> * Increasingly, I don't like UFCS. I think that in most cases, it
>> complicates
>> code for little value. And I _really_ don't like how it results in people
>> flipping chains of a(b(c(d(5)))) calls into something like
>> d(5).c().b.().a(). I
>> think that it makes the code way harder to read.
>
> For me it makes that kind of code way simpler to read...

Completely agree.

>
>
>> The code is completely backwards.
>
> It means call d on 5, then call c on the result, then call b on the
> result, and then call a on the result. It's better than before :-)

Amen.

>
> Bye,
> bearophile

-- 
- Alex

On 29-04-2012 03:40, Jonathan M Davis wrote:
> On Sunday, April 29, 2012 03:06:53 bearophile wrote:
>>> * Increasingly, I don't like UFCS. I think that in most cases,
>>> it complicates
>>> code for little value. And I _really_ don't like how it results
>>> in people
>>> flipping chains of a(b(c(d(5)))) calls into something like
>>> d(5).c().b.().a(). I
>>> think that it makes the code way harder to read.
>>
>> For me it makes that kind of code way simpler to read...
>>
>>> The code is completely backwards.
>>
>> It means call d on 5, then call c on the result, then call b on
>> the result, and then call a on the result. It's better than
>> before :-)
>
> I know that you find easier to read. A number of people do. But it is just so
> backwards in comparison to how stuff normally works, that it hurts my brain.
> But I've done enough functional programming that I find something
> likea(b(c(d(5)))) to be completely straightforward, and for some reason not
> everyone does. And while I _never_ intend to use UFCS in this manner, I'm
> going to forever have to read the code of others who do, which I find to be a
> major negative.

I've done ML, F#, Erlang, Haskell, Lisp, and others, and I still don't like that style. It's the very reason F# has the pipelining operators like |> and <|.

>
> But regardless of my personal opinion on the matter, it's clear that enough
> people like UFCS that it's not going anywhere unless something seriously wrong
> is found with it which makes it untenable.
>
> - Jonathan M Davis


-- 
- Alex

On Sunday, 29 April 2012 at 20:00:27 UTC, Alex Rønne Petersen wrote:
>
> Let's get a standard package manager that we either advocate on dlang.org or include in the releases before we start talking about reducing the amount of modules in Phobos.

Don't get me wrong. I don't want to reduce the amount of modules in Phobos. I think it's a great standard library.
A little bit buggy in some places, and lacks a few important features (that are in the review queue), but great overall.
I fear the risk with a package system is, having some parts of Phobos not being correctly maintained with time. And I want to be able to have the whole thing with a single download.
No, my concern was, for smaller applications, in embedded systems for instance (Android, iOS, etc), there is not really a small basic library. So I would think of a two level standard library, one on top of the other.
OTOH, Jonathan Davis made the remark that we can always use the C lib and its bindings, so this mostly satisfies my concern.

On 4/29/12, Alex Rønne Petersen <xtzgzorex@gmail.com> wrote:
> I hate to nitpick and all that, but opBinaryRight!"in" actually works now. ;)

Yes and then you get to have those nice template instantiation errors, which make no sense at all:

struct Foo {
    auto opIn_r(string op)(int i) { return 1; }
}

struct Bar {
    auto opBinaryRight(string op)(int i) { return 1; }
}

void main()
{
    Foo foo;
    auto x = "" in foo;

    Bar bar;
    auto y = "" in bar;
}

Foo:
test.d(34): Error: template test.Foo.opIn_r does not match any
function template declaration
test.d(16): Error: template test.Foo.opIn_r(string op) cannot deduce
template function from argument types !()(string)

Bar:
test.d(37): Error: rvalue of in expression must be an associative array, not Bar

The Bar error message is completely useless.

On 29-04-2012 03:20, ponce wrote:
> Le 28/04/2012 20:47, Walter Bright a écrit :
>> What's your list?
>
> - builtin complex types (I don't _need_ be able to write "4 + 5i")

+1.

> - builtin associative arrays
> - some builtin properties like arr.sort

+1, and .reverse. I'm also against .dup and .idup being properties, but these don't modify the array in place, so I take less issue with them.

> - lazy, I use it only for logging

lazy is horribly broken in many ways. Try to make a lazy value where the producing delegate is pure.

(Hint: You can't.)

> - foreach_reverse, never used it
> - comma operator: when do you ever need it?

I've never used it intentionally, ever, but have been bitten in the ass countless times because of it.

> - in operator

Disagree. However, I do think it needs to made more useful (for instance, I simply don't understand why I can't use in to test for existence in an array).

>
>
> Other than that, as a user I can't say having a lot of features is a big
> problem, it's a major selling point.


-- 
- Alex

On 4/29/12, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:
> struct Foo {
>     auto opIn_r(string op)(int i) { return 1; }
> }

Sorry that's wrong, should be:
struct Foo {
    auto opIn_r(int i) { return 1; }
}

And then you get:
test.d(25): Error: function test.Foo.opIn_r (int i) is not callable
using argument types (string)
test.d(25): Error: cannot implicitly convert expression ("") of type
string to int

which much better than Bar's error message.

On 29-04-2012 08:31, Paulo Pinto wrote:
> Am 28.04.2012 20:47, schrieb Walter Bright:
>> Andrei and I had a fun discussion last night about this question. The
>> idea was which features in D are redundant and/or do not add significant
>> value?
>>
>> A couple already agreed upon ones are typedef and the cfloat, cdouble
>> and creal types.
>>
>> What's your list?
>
> - two different ways of creating function pointers is confusing
> (function and delegate)
>
> I understand the reasoning, but makes one think all the time when
> to use what.
>
> - sometimes D code looks like template and mixins gone mad
> While I do appreciate the power, it can be quite confusing to try
> to understand what the code does. Specially with the lack of support
> in mixin's debugging
>
> - __traits should be given a proper name
> It looks out of place in regard with the rest of the language, by making
> use of the underscores
>
> - AA should be a library type
> I am on the C++ and Scala camp where the language should be extendable
> via the library
>
> - misuse of enum to declare constants
> I prefer that the use of const would be possible
>
> - conditional compilation is hard to follow without syntax highlighting
> Other languages with conditional compilation make it easier to follow
> what is what. e.g. Turbo Pascal/Delphi, C#, Modula-3, Ada
>
> - unit tests
> I would rather have them as a library.

D unit tests were never really useful for anything beyond single-library projects IMHO. They don't scale for large, real-world application projects with lots of libraries and executables.

>
> While it is fun to discuss what we like and not like, I vote that
> priority should be given to make the language stable and have better
> tooling.
>
> We need to have safer languages with native code generation for systems
> programming in the mainstream OS, that take us away from the buffer
> overflow exploits and dagling pointers legacy that C and C++ brought
> upon us.
>
> Someone that does not know D and sees the amount of bugs still existing,
> or this type of discussions, will run away to Go or some future version
> of C#/Spec#/Bartok, or back to whatever he/she was using before.
>
> I don't agree D is complex, any language that aims to be used in large
> application domains, needs a certain set of abstractions. If it does not
> support them, it is condemmend to keep getting new features until it
> turns in what the language designers were fighting against.
>
> --
> Paulo


-- 
- Alex

Alex Rønne Petersen:

>> - lazy, I use it only for logging
>
> lazy is horribly broken in many ways.<

Sometimes I use std.exception.enforce(), that uses lazy.

Bye,
bearophile

Alex Rønne Petersen:

> D unit tests were never really useful for anything beyond single-library projects IMHO. They don't scale for large, real-world application projects with lots of libraries and executables.

I think D has to offers means to library writers to instrument the built-in unit-testing machinery, to allow the implementation of a good unit testing system.

Bye,
bearophile