On Saturday, 28 April 2012 at 20:50:30 UTC, H. S. Teoh wrote:
> On Sat, Apr 28, 2012 at 09:22:59PM +0200, q66 wrote:
>> - Phobos is too fat - it needs to shrink to just a few core modules,
>> others being distributed via some system like CPAN for Perl
>
> Um... that's what a *library* is supposed to be: a large collection of
> useful stuff from which you can pick the few that you need right now.

 And the STL and libc isn't big? Size is only intimidating if you don't know what your looking for. Having to scour in std.ascii, then std.utf, then std.array or other locations when your looking for something can get a little annoying. But it's a learning curve, once you know it you tend to find the functions and information fairly quickly.

 More likely a good tutorial through the library would alleviate some of that, or just the parts that are more confusing. One part for example involving conversion for unicode, I still have no idea how to convert Latin1String (extended ascii) to utf so I could use all of phobos's power; So I've ended up writing my own little conversion function for that. It's going to come down that stuff we write and post up that we think is self explanatory isn't because as the implementers we understand it in intimately.

On Saturday, 28 April 2012 at 21:58:47 UTC, H. S. Teoh wrote:
> On Sat, Apr 28, 2012 at 11:42:31PM +0200, Peter Alexander wrote:
> [...]
>> - UFCS. It's just sugar, but adds complexity.
>
> On the contrary, it's a major helper for writing generic code. In my new
> AA implementation, I use UFCS to provide a default toHash function for
> all types that don't already provide one. Without UFCS, this would
> require lots of ugly hacks and constraints on how user code can provide
> custom hash functions. (Due to the way D overloading works, UFCS is
> currently the only way to provide a default function without causing a
> conflict at compile-time.)

The problem there is that toHash is a member function. That UFCS is helpful in working around other problems in D is not a good argument for its existence IMO.

To be honest, I don't like the idea of member functions at all. Having two syntaxes for calling a function is the core problem, and UFCS is just an extra complication on top of it to try and mitigate the original problem.

f(x) ---> x.f() is not progress in language design.


>> - const/immutable/inout/shared/pure. These add massive complexity to
>> the language for little (IMO) benefit. When I do multi-threading, I
>> usually have to resort to casting. Maybe these will improve with
>> time.
>
> Yeah they are complex, but they also open ways for powerful
> optimizations by the compiler.

In theory. IMO the amount of time you spend trying to please the type system could have been better spent optimizing your code manually.

No code I have ever written would benefit significantly from these potential optimisations. For example, one optimisation is that pure function calls could be hoisted out of loops. Great, except that if that function call had any significant cost whatsoever, I would have already done that optimisation myself.


>> - opDispatch. I think it just promotes sloppy, obfuscated code for
>> minor syntactical benefit.
>
> Wrong.

It's my opinion. You are free to disagree, but opinions can't be wrong.

I've seen no good uses of opDispatch so far. If you can point me towards some code that justifies its use then please let me know about it.

On 29 April 2012 00:42, Peter Alexander <peter.alexander.au@gmail.com>wrote:

> On Saturday, 28 April 2012 at 18:48:18 UTC, Walter Bright 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?
>>
>
> Here's my list:
>
> - Properties. They add no value and just start pointless discussions about what should and shouldn't be a property.
>
> - UFCS. It's just sugar, but adds complexity.
>
> - const/immutable/inout/shared/**pure. These add massive complexity to
> the language for little (IMO) benefit. When I do multi-threading, I usually
> have to resort to casting. Maybe these will improve with time.
>
> - opDispatch. I think it just promotes sloppy, obfuscated code for minor syntactical benefit. Member access through pointers should require -> like in C++ so that you can overload it for smart pointer/reference ADTs.
>
> That's all I can think of for now.
>

I disagree with every one of those points, except maybe 'shared', which seems like a good idea in theory, but I think it's completely broken (every interaction requires an explicit cast, and there is no facility for transfer of ownership, which is a VERY common operation in my experience)

On 04/28/2012 11:42 PM, Peter Alexander wrote:
> On Saturday, 28 April 2012 at 18:48:18 UTC, Walter Bright 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?
>
> Here's my list:
>
> - Properties. They add no value and just start pointless discussions
> about what should and shouldn't be a property.
>
> - UFCS. It's just sugar, but adds complexity.
>
> - const/immutable/inout/shared/pure. These add massive complexity to the
> language for little (IMO) benefit. When I do multi-threading, I usually
> have to resort to casting. Maybe these will improve with time.
>
> - opDispatch. I think it just promotes sloppy, obfuscated code for minor
> syntactical benefit. Member access through pointers should require ->
> like in C++ so that you can overload it for smart pointer/reference ADTs.
>
> That's all I can think of for now.


- UFCS:
   The complexity comes from having multiple function invocation
   syntaxes. UFCS actually makes that situation better without adding a
   lot of complexity to the compiler implementation.

- const/immutable/shared/pure
   shared: The fact that everything that is not marked as shared is
   actually thread-local is extremely important. I think most other
   imperative languages got this wrong.
   But if shared is explicit in the type system, immutable really
   should be explicit too. The sad part is that the qualifiers don't
   play nicely with reference types at the moment.

- opDispatch
   This is useful and of significant value if used the right way.
   I hope you are not actually serious about that '->' part.

On 04/28/2012 10:24 PM, Timon Gehr wrote:
> On 04/28/2012 08:47 PM, Walter Bright 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?
>
>
> - Associative array literals as non-associative array initializers [1]
> - C style array declarations [2]
> - 'align' declaration [3]
> - 'synchronized' [4]
> - special treatment of built-in types during parsing [5]
> - the arcane restrictions on which exact kind of argument can be
> used to substitute which kind of template parameter
>
>

Oh, completely forgot about that one:

- 'in' operator returning a pointer to the element.

On 29 April 2012 01:09, F i L <witte2008@gmail.com> wrote:

> On Saturday, 28 April 2012 at 18:48:18 UTC, Walter Bright 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?
>>
>
> First, I completely agree with some points already made here, and I completely disagree with a few others.
>
> A modern compiler should be as powerful and convenient as possible, I completely disagree that a compiler can't do a broad range of things very efficiently _and_ with a smooth learning. Indeed this is what attracted me to D in the first place, the idea that it has the low level power of C++ when you get down to it, but it's also attractive and initially easy to use.
>
>
>
> What I think should be removed/changed:
>
> - Drop is( ... ) and extend "__traits()" (however "__traits" should become
> .metaof or something along those lines). Also, a easy to understand traits
> lib should be imported by default like Object.d
>
> - Enum as manifest constant - I agree, this is better as "static x = 10" or equivalent. I was actually confused at first when I realized enum's where what was *supposed* to be used for that.
>
> - foreach_reverse. Dmitry's gave a good alternative. Though, I think a more intelligent 'foreach' (or even 'for') statement could address this as well. Something like:
>
>    for (key, value of range, step) {
>        ...
>    }
>
>    // Where step values which can be deduced at compile time
>    // are used to produce the most optimizated code.
>
> - version statements - this would be a lot more consistent as a static if() I think. But it does need a more obvious syntax, possibly something like:
>
>    static if ("foo" in Compiler.flags) {
>        ...
>    }
>
> - .di files - I agree with foobar here. Other language have had this for awhile, and it makes linking a much easier concept.
>
> - NaN as default - I've said this before on here, but I think it deserves being said again. FP values defaulting to Nan is a debugging feature, and should be explicitly expressed in areas which need to guarantee a variable is set after declaration. A useful, and consistent default should be used instead. Ints (the other number type) default to zero, and because zero is the most practical and commonly understood, FP values should start here as well.
>
> - commas - should be use for tuples and parameters, not as ending marks:
>
>    int, int foo() { return 5, 6; }
>
>    auto x, y = 2;    // x = 0, y = 2
>    auto x, y = 2, 3; // x = 2, y = 3
>
>    x, y = foo();     // x = 5, y = 6
>
>
>
> What should stay:
>
> - foreach (or an intelligent 'for' as exampled above). This is an incredibly convenient, tried 'n true feature.
>
> - built-in Associative Arrays - one of D's sexiest features. It's very useful for many things, and always having it at your disposal is a logical choice.
>
> - properties - another incredibly convenient feature. I think a more sexy implementation of properties are in order, but the construct is great. It would be nice to have properties as a language type, rather than a attribute:
>
>    struct Foo {
>        property int x { get; private set; }
>        property int y {
>            get()    { return x; }
>            set(T t) { x = t; }
>        }
>    }
>
>    // Or the syntax could follow Types:
>
>    property x : int { ... }
>
>    // Which could be templated:
>
>    property y(T = int) : int {
>        static if (T.isType!int) {
>           ...
>        }
>        else {
>           ...
>        }
>    }
>
> - with statement - no reason to kill it really and it's useful in some places. Helps keep code short and readable.
>
> - Anonymous class - There's no reason to remove this feature, it's not hurting anyone and it could allow for interesting frameworks similar to jQuery.
>
>
>
> Other things that would be cool:
>
> - static foreach
>

Hear hear.
I completely agree with everything you just said.

On Sun, Apr 29, 2012 at 12:39:03AM +0200, Timon Gehr wrote:
> On 04/28/2012 10:24 PM, Timon Gehr wrote:
> >On 04/28/2012 08:47 PM, Walter Bright 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?
> >
> >
> >- Associative array literals as non-associative array initializers [1]
> >- C style array declarations [2]
> >- 'align' declaration [3]
> >- 'synchronized' [4]
> >- special treatment of built-in types during parsing [5]
> >- the arcane restrictions on which exact kind of argument can be
> >used to substitute which kind of template parameter
> >
> >
> 
> Oh, completely forgot about that one:
> 
> - 'in' operator returning a pointer to the element.

Yeah that one elicited a WAT from me when I first started using it. Surprisingly enough, it sounded OK when I read it in TDPL, but when I started using it I realized just how b0rken it is.


T

-- 
People tell me that I'm paranoid, but they're just out to get me.

On Saturday, April 28, 2012 22:00:52 bearophile wrote:
> 2) I'd like to disallow (or fix!) default arguments of out and
> ref arguments (http://d.puremagic.com/issues/show_bug.cgi?id=5850
> ).

If the changes to ref and const ref that were discussed during the beta are fully fleshed out and implemented, then it'll be perfectly legal to pass a temporary value to a ref in many cases (if not in general), in which case having them take a default argument wouldn't be a problem at all. But as long as ref can't take temporaries, having it take a default argument makes no sense at all.

> 3) Automatic joining of adjacent strings (a bug-prone
> anti-feature: ["red" "green", "blue"]).

Agreed.

- Jonathan M Davis

On Sunday, April 29, 2012 00:39:03 Timon Gehr wrote:
> Oh, completely forgot about that one:
> 
> - 'in' operator returning a pointer to the element.

Really? I use that all the time with AAs. Without that, you would have to do two lookups to get an object which might not be in the container, so it would be less efficient. I'd hate it if in stopped returning a pointer. We'd just have to add some other function which does the exact same thing as in now, and then I'd use in a _lot_ less.

- Jonathan M Davis

On Saturday, April 28, 2012 13:43:27 H. S. Teoh wrote:
> D has typedef?? Wow. And I thought I had a good grasp of D.

It did, but it won't. It's either already been deprecated or will be soon.

- Jonathan M Davis