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.)


> - 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.

Though I do have to say that inout needs some serious reconsideration, since the way they work currently is ambiguous when you have more than one inout argument, or when you have a delegate parameter with inout arguments.


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

Wrong. It's a powerful tool for building runtime dynamic class loading. It allows you to write generic code that Just Works without having to special-case them for statically-known classes vs. dynamic classes. If anything, I'd argue for *more* similar features that let you write generic code that integrates seamlessly into the language.

Just because it's been used (arguably abused) for things like making roman numerals or vector swizzling, doesn't mean it's a bad feature.


> Member access through pointers should require -> like in C++ so that you can overload it for smart pointer/reference ADTs.
[...]

Yikes!! Please don't reintroduce that monstrous -> operator from C++! (Besides, most of the time idiomatic D code doesn't even need pointers.)


T

-- 
If you look at a thing nine hundred and ninety-nine times, you are perfectly safe; if you look at it the thousandth time, you are in frightful danger of seeing it for the first time. -- G. K. Chesterton

On Sat, Apr 28, 2012 at 11:58:19PM +0200, deadalnix wrote: [...]
>  - is is messed up. It is a massive hack and have to be rationalized.

As I said in another thread, the _functionality_ of various is() expressions are very useful and should be kept. But the _syntax_ is completely b0rked and needs some serious redesign.


>  - version is a bad version of static if. The static if part of the
> version must go.

What's your proposal?


>  - comma expression is confusing and have very little benefice.

+1. I say that D3 should drop the comma operator. Esp. when doing so will open up the way for having native syntax for tuples. Needing to resort to Phobos to have a way to name a compiler-supported type is backwards and silly.


>  - out arguments. We can return tuples, out argument is going
> backward in history.

Not when there's no way to name tuples without resorting to Phobos (or
copy-n-paste Phobos code).


>  - many array properties (.sort for instance) are useless and would
> be way better as libs.

Yeah, .sort is redundant, and besides shouldn't be an array "property" to begin with.


T

-- 
What's a "hot crossed bun"? An angry rabbit.

On Saturday, 28 April 2012 at 20:59:48 UTC, q66 wrote:
> On Saturday, 28 April 2012 at 20:35:40 UTC, SomeDude wrote:
>
> This kind of attitude "we need big fat bullshit like Java and heavy use of OO and idioms and EH and all that other crap" is broken and false. And you have no way to prove that Python for example wouldn't scale for large projects; its main fault is that the default implementation is rather slow, but it's not pretty much missing anything required for a large project.

BTW, look at Scala for another language that's designed for large scale programming (as its name implies). Scala is a very good design, some even think it's the Java killer. But I think it's even more complex than D.

On Sat, Apr 28, 2012 at 11:57:46PM +0200, SomeDude wrote:
> On Saturday, 28 April 2012 at 21:51:42 UTC, deadalnix wrote:
> > - out arguments. We can return tuples, out argument is going
> >backward in history.
> > - many array properties (.sort for instance) are useless and
> >would be way better as libs.
> 
> What happens the day the language is actually fit for embedded programming, and you don't want to have to link against Phobos because it's too big ?

We need to fix things so that using a single feature in Phobos will not pull in the entire library. That's an implementation issue, not a language issue.


T

-- 
LINUX = Lousy Interface for Nefarious Unix Xenophobes.

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

On 04/28/2012 11:04 PM, Dmitry Olshansky wrote:
> On 29.04.2012 0:57, Timon Gehr wrote:
>> On 04/28/2012 09:22 PM, Dmitry Olshansky wrote:
>>> 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.
>>
>> static is not accessible at compile time, would you want to change that?
>> immutable is not an option because it infects the type.
>>
> Oops, scratch that comment about static/immutable.
>
> But how about:
> alias thing = runSomeCtfe();
>

That would work in certain cases, where the initializer is not a single symbol. But then, I kinda like the way 'enum' is generalized in D:

enum Foo{
    member1,
    member2,
    member3,
}

=> (allow non-integral enumerations)

enum Foo{
    member1 = "1",
    member2 = "2",
    member3 = "3",
}

=> (anonymous enums)

enum{
    member1 = "1",
    member2 = "2",
    member3 = "3",
}

=> (a single member is okay)

enum{
    member1 = "1",
}

=> (syntactic sugar)

enum member1 = "1";

> And bring the usual alias to new_name = <something>;
> form (even C++ finally got this right with C++11 aliases).
>

This is probably something that should be done.

>> I actually think D is not too large.
>
> For what it does - surely not. But in general it's big.
> For one it's not smaller then C++.

I am not sure how to compare, but D 'feels' smaller than C++ to me.

Implementing a compiler is probably harder for D, because of the interplay of forward references, CTFE and compile time introspection.

Le 29/04/2012 00:04, H. S. Teoh a écrit :
> On Sat, Apr 28, 2012 at 11:58:19PM +0200, deadalnix wrote:
> [...]
>>   - is is messed up. It is a massive hack and have to be rationalized.
>
> As I said in another thread, the _functionality_ of various is()
> expressions are very useful and should be kept. But the _syntax_ is
> completely b0rked and needs some serious redesign.
>

That is what I meant.

>
>>   - version is a bad version of static if. The static if part of the
>> version must go.
>
> What's your proposal?
>

version(foobar) returning a boolean at compile time for instance.

>
>>   - comma expression is confusing and have very little benefice.
>
> +1. I say that D3 should drop the comma operator. Esp. when doing so
> will open up the way for having native syntax for tuples. Needing to
> resort to Phobos to have a way to name a compiler-supported type is
> backwards and silly.
>
>
>>   - out arguments. We can return tuples, out argument is going
>> backward in history.
>
> Not when there's no way to name tuples without resorting to Phobos (or
> copy-n-paste Phobos code).
>

See how both go together. Remove comma expression, get a nice tuple syntax, and then remove out parameter seems a nice way to go.

On Sat, Apr 28, 2012 at 11:12:38PM +0200, SomeDude wrote:
> On Saturday, 28 April 2012 at 20:59:48 UTC, q66 wrote:
> >
> >This kind of attitude "we need big fat bullshit like Java and heavy use of OO and idioms and EH and all that other crap" is broken and false. And you have no way to prove that Python for example wouldn't scale for large projects; its main fault is that the default implementation is rather slow, but it's not pretty much missing anything required for a large project.
> 
> Python has two big drawbacks for large projects:
> - it's too slow
> - it's a dynamically-typed language
> 
> The fact that it's flexible is because it uses duck typing, and
> AFAIK you can't do duck typing in a statically typed language.
> So it's cool for small programs, but it can't handle large ones
> because it's not statically typed. And this opinion doesn't come
> just out of thin air, I speak from my own professional experience.

Who says D doesn't have duck-typing?

	template isADuck(T) {
		alias isADuck = is(typeof(T.quack())==bool);
	}

	void petADuck(T)(T duck)
		if (isADuck!T)
	{
		duck.quack();
	}

You can pass anything that has a quack() method to the function:

	struct CanadianDuck {
		void quack() { writeln("Quack, eh?"); }
	}

	class AmericanDuck {
		void quack() { writeln("Quack, yo!"); }
	}

	struct RubberDuck {
		void opDispatch!(string S)()
		{
			auto d = loadRuntimeDuckClass();
			d.callMethod(S);
		}
	}

	struct Cow {
		void moo() { writeln("Mooo!"); }
	}

	void main() {
		CanadianDuck caddie;
		AmericanDuck quacker = new AmericanDuck;
		RubberDuck runtimeDuck;
		Cow orker;

		// Look, ma! I hez duck-taiping!
		petADuck(caddie);
		petADuck(quacker);
		petADuck(runtimeDuck);

		// Reject non-duck objects
		petADuck(orker);	// compile error: orker is not a duck!
	}

Not only D supports duck-typing, the compiler even checks type-safety for you at compile-time. ;-)

Incidentally, this is what the Phobos range interface does.


T

-- 
My program has no bugs! Only undocumented features...

On Saturday, 28 April 2012 at 22:04:26 UTC, H. S. Teoh wrote:
> On Sat, Apr 28, 2012 at 11:57:46PM +0200, SomeDude wrote:
>> 
>> What happens the day the language is actually fit for embedded
>> programming, and you don't want to have to link against Phobos
>> because it's too big ?
>
> We need to fix things so that using a single feature in Phobos will not
> pull in the entire library. That's an implementation issue, not a
> language issue.
>
>
> T

It is, but it's actually a very difficult implementation issue. And what I currently see is, many Phobos bugs are simply not corrected, while DMD bugs actually are. It seems that noone but Andrei is working on Phobos. And he is only part time on it.
Also, ranges are cool, but they are big. And not everyone wants to have to huge ranges when they can use simpler, and arguably faster arrays.

I'm not very satisfied with the current state of Phobos. Being the standard library, it should *work*. Yet it seems to me some things simply don't work at all. The new regex, for instance, I've yet to compile anything with it. The author argues the CTFE is broken, but even the runtime regex doesn't compile. That's not acceptable in a standard library.
So before thinking about removing these little features from the core language, thoses issues with Phobos must first be solved.

On 28 April 2012 21:47, Walter Bright <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.
* 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.