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?

Le 28/04/2012 20:47, Walter Bright a écrit :
> 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 think many D features come from the lack of AOP in D. I already mentioned that in some other thread.

I would also mention the is expression which does way too many stuffs and many of them are not usefull or counter intuitive and may be replaced by lib support in std.traits .

"Walter Bright" <newshound2@digitalmars.com> wrote in message news:jnhe1i$2vcm$1@digitalmars.com...
> 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?

Off the top of my head:

- Using function stubs so the implementation can be provided in a separate source and linked in. (Outside of .di files anyway.)

- Comma operator

- Version blocks: They should be replaced with something that utilizes "static if".

On 28.04.2012 22:47, 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?


1. Drop is(...) feature entirely. Extend __traits where needed and move compile-time reflection to "magic" meta namespace completely.

2. "enum as manifest constant". Use static or immutable/global. Compiler should be smart enough to avoid putting immutable integers/doubles into object file as variables.

3. with statement (?). I kind of like it but bleh it's too boggy and it doesn't seem to pull its weight. (pointers? class references? a lot of stuff to go wrong) Fluent interfaces solve a good portion of its benefits to be specific.

4. foreach_reverse. Seriously let's kill this abomination. If it happens that foreach(x; retro(range)){...} is slower it just means compiler (inlining?) is no good and should be improved.

5. .tupleof looks like a hack. But I'd rather "refactor" than drop it.

6. Drop out arguments? There are tuples.
And auto (a, b) = getMeTwoThings();  is cleanerthan
<something> a, b;
fillTheseTwoThings(a, b);
// no indication whatsoever that a & b are modified heck even fn(&a, &b) in C is *better*
(ok no tuple unpacking for now but you got the idea)

7. I can live without homogenous varaidics. Since most of the time they readily progress to full-blown variadics that detect common type & forward things to an array version of function. Also given that sometimes people do things like:

this(int[] arr...)// ctor with cool syntax, yada-yada ;)
{
	this.data = arr; //boom! (pointer to stack-allocated stuff)
}

8. Something else. D is huge :)

-- 
Dmitry Olshansky

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?

- AAs integrated in the language; you barely ever use AA literals and having them purely in Phobos would help get rid of the runtime fat, as well as better implementations
- Phobos is too fat - it needs to shrink to just a few core modules, others being distributed via some system like CPAN for Perl
- Properties - they're kinda broken at this point and the value is questionable
- @trusted @system
- Exception handling - a lot of runtime, questionable value
- Versions - not redundant, but needs a better system (with AND/OR, possibility of de-versioning, the assignment op to set versions is kinda bad)

I think I would find some more, but these are the ones I can recall now.

On 4/28/12, Walter Bright <newshound2@digitalmars.com> wrote:
> What's your list?

I don't mind extra features, just as long as they're properly documented and implemented. For example, I have absolutely no uses for anonymous classes right now, but I know DWT2 uses them and probably other people do use them.

Personally I find the hardest threads to to follow are the ones discussing in/out/inout/autoref. For one thing there are compiler bugs, but then there are misconceptions between what developers vs documentation vs core devs say about them. And then you mix in classes and templates into the story and it all becomes a large forest of information that is very hard to digest.

Another feature I'm curious about is .dup/.idup. It's basically hardcoded for a couple of types, but why not instead use UFCS and implement .dup/.idup in std.array as a free function? Then you might even use it for user-types by requiring a type to implement .dup/.idup functions.

Also there's mixin templates. What exactly is the difference between mixin templates and regular templates? We can use the mixin statement for both types right now, so there doesn't seem to be a distinction. For example, if you take samples from the template mixin page (http://dlang.org/template-mixin.html) and you remove "mixin" from the template declaration, all of the samples will continue to work. You could remove this declaration feature right now and you probably wouldn't break any code at all. Seems like low-hanging fruit to me.

"q66" <quaker66@gmail.com> wrote in message news:ihqjguujvoukhlqcwkyi@forum.dlang.org...
>
> - Phobos is too fat - it needs to shrink to just a few core modules,
> others being distributed via some system like CPAN for Perl
> - Properties - they're kinda broken at this point and the value is
> questionable
> - @trusted @system
> - Exception handling - a lot of runtime, questionable value

That's just craziness!

On Saturday, 28 April 2012 at 19:23:00 UTC, q66 wrote:
>
> - AAs integrated in the language; you barely ever use AA literals and having them purely in Phobos would help get rid of the runtime fat, as well as better implementations
> - Phobos is too fat - it needs to shrink to just a few core modules, others being distributed via some system like CPAN for Perl
> - Properties - they're kinda broken at this point and the value is questionable
> - @trusted @system
> - Exception handling - a lot of runtime, questionable value
> - Versions - not redundant, but needs a better system (with AND/OR, possibility of de-versioning, the assignment op to set versions is kinda bad)
>
> I think I would find some more, but these are the ones I can recall now.

I disagree with every single point here.

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?

D has a lot of ad-hock features which make the language
needlessly large and complex. I'd strive to replace these with
better general purpose mechanisms.

My list:
* I'd start with getting rid of foreach completely. (not just
foreach_reverse). This is nothing more than a fancy function with
a delegate parameter.

* enum - enum should be completely redesigned to only implement
what it's named after: enumerations.

* version - this does not belong in a programming language. Git
is a much better solution.

* di files - a library should encapsulate all the info required
to use it. Java Jars, .Net assemblies and even old school; Pascal
units all solved this long ago.

* This is a big one: get rid of *all* current compile time
special syntax. It should be replaced by a standard compilation
API and the compiler should be able to use plugins/addons. This
would reduce the size of the language to half of its current
size, maybe even more.

Walter:

> which features in D are redundant and/or do not add significant value?
>...
> What's your list?

Finding things to remove now from D is hard, in my code I have used most D features now. And many suggestions I have seen in this thread are very bad, like removing foreach_reverse (that I use often), or "Phobos is too fat" (that is the opposite of what I'd like, I'd like D with more batteries).

The features I have not used in my programs so far are:

1) Typesafe Variadic Functions for class objects (never used so far).
2) >>>=  >>> (Never used so far).
3) Floating point comparison operators (never used).
4) Delimited Strings / heredoc strings (never used so far in real code, despite Perl programmers use them now and then).
5) lazy (as function argument. I have used "lazy" in some test programs, but not in real code so far).
6) Anonymous classes (used only in demo code so far).
7) Shortened floating point literals as .6 or 6.


Other things that I don't like:
1) Mixed C/D array declarations (http://d.puremagic.com/issues/show_bug.cgi?id=5807 )
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 ).
3) Automatic joining of adjacent strings (a bug-prone anti-feature: ["red" "green", "blue"]).
4) Comma operator, it gives more troubles than flexibility.
5) The most complex parts of the is() syntax (to be replaced with other things).
6) Two kinds of tuples. I'd like a single tuple type in a language, but I understand this is hard to do.

-------------------------

I'd also like to see some limits removed like:

struct Foo {}
void main() {
  auto f = new Foo; // currently not accepted, silly
}


BigInt x;
switch (x) {
  case BigInt(0): break;
  default:
}


And I'd like some features added/improved, like:
- tuple unpacking syntax;
- computed gotos;
- a static foreach (http://d.puremagic.com/issues/show_bug.cgi?id=4085 );
- attribute hiding error or warning (http://d.puremagic.com/issues/show_bug.cgi?id=5187 );
- safer typesafe variadics (http://d.puremagic.com/issues/show_bug.cgi?id=5212 );
- Named arguments;
And few other things.

Bye,
bearophile