On 29-04-2012 14:26, David Nadlinger wrote:
> On Saturday, 28 April 2012 at 18:48:18 UTC, Walter Bright wrote:
>> What's your list?
>
> My personal list of features I could easily live without – some of these
> might be controversial, but yes, I have written non-trivial amounts of
> code in both D1 and D2:
>
> - Anonymous nested classes: They might be useful in Java, particularly
> in older incarnations, but not so much in D – never used them.

I use them. They can be useful when you're writing more object-oriented code than functional style code.

>
> - Comma operator: Kill it with extreme prejudice, it is an anti-feature
> (allow it in for loop expressions if you really want to, but I think
> there are better solutions).

+9001.

>
> - Typesafe variadics: They look nice on paper, but I haven't used them
> once. Often, you either explicitly need C-style variadics, or you want
> to accept e.g. multiple ranges of the same element type, where you need
> template variadics anyway.
>
> - Unsigned right shift, but I can see how it can be useful (simply
> underused?).

It's clear that arithmetic right shift is what the programmer usually wants, and yet, we use >> to denote what they don't want. It's completely counter-intuitive.

So, +1.

>
> - HexString, DelimitedString, r""-WysiwigString, TokenString: I didn't
> ever use the former two (for including binary data in the program,
> ImportExpression is imho much easier than generating a source file
> containing a HexString). As for r"", every time I actually need
> WysiwigString, I use backticks, because such strings often contain
> quotes anyway. Regarding TokenString(i.e. q{}) – it is certainly a very
> nice idea, especially regarding syntax highlighting, and I occasionally
> use them for CTFE code generation. But without any kind of support for
> string interpolation, I typically find myself using normal strings for
> everything except small self-contained portions of code (where mixin
> templates would probably be cleaner). The problem is that can't just
> »interrupt« q{}s strings to do something like »q{…} ~ identifierName ~
> q{…}«, because there will most likely be unmatched braces – but this is
> needed in assembling mixin strings all the time…
>
> - Concatenation of adjacent strings: Also an anti-feature, imho.

+1.

>
> - Floating point comparison operators like !<>= (yes, that _is_ valid D
> code): I must admit that I seldom write code relying on the finer
> details of IEEE-754 semantics, but can't they just be »lowered« to a
> combination of the more common ones?

Why not just make them intrinsics? What are they doing in the language? You're rarely, if ever, going to actually be using these operators because NaN is, well, an invalid state, like null.

+1.

>
> - »Short« floating point literals like .4 instead of 0.4 and 4. instead
> of 4.0 – the saved characters are not worth the syntax special cases,
> especially w.r.t. UFCS.

+1. I find it to be poor style to not include the ".0" in FP literals.

>
> - new/delete issues have been discussed many times
>
> - Built-in arrays and AAs: They are convenient to use, but as far as I
> can see the single biggest GC dependency in the language. Why not lower
> array and AA literals to expression tuples (or whatever) to make the
> convenient syntax usable with custom (possibly non-GC safe) containers
> as well? A GC'd default implementation could then be provided in
> druntime, just like today's arrays and AAs.

Sounds reasonable.

>
> - shared: TLS by default is great, but only __gshared is really usable
> right now. IMHO, shared had better been reserved for a comprehensive
> take on the subject, rather than the half-baked implementation we have
> right now.
>
> David

It's clear that shared is biased towards heavily templatized code. It's not useful in non-templatized code because such code can't accept both shared and non-shared values.

shared looks neat in theory, but is a fallacy in practice.

-- 
- Alex

On 29-04-2012 21:19, David Nadlinger wrote:
> On Sunday, 29 April 2012 at 12:26:13 UTC, David Nadlinger wrote:
>> On Saturday, 28 April 2012 at 18:48:18 UTC, Walter Bright wrote:
>>> What's your list?
>>
>> My personal list of features I could easily live without – some of
>> these might be controversial, but yes, I have written non-trivial
>> amounts of code in both D1 and D2:
>
> What I forgot to mention:
> - VersionCondition: Just provide a mechanism to map command line flags
> to constants, probably in a magic »version« namespace, and use static if
> (e.g. »version (Foo)« -> »static if (version.Foo)«, »version (unittest)«
> -> »static if (unittest)«).

Something like that seems reasonable. At any rate, version in its current state is not very useful in practice.

>
> - DebugCondition: Hardly used in practice, at least not in ways that
> couldn't easily be replaced with a static if (resp. version). It is a
> frequent source of confusion for newcomers that -debug is orthogonal to
> -O/-release, and I'm not too fond of the purity »escape hatch« built in
> (why not just use casts in those rare cases?).

+1. And debug being a keyword is more annoying than you'd think.

>
> David

-- 
- Alex

On Saturday, 28 April 2012 at 23:41:29 UTC, Peter Alexander wrote:
>
>> But in D the main purpose of "pure" is not as optimization tool, but more as a tool to enforce a better coding style, that makes code understanding (and testing simpler), and helps avoid some bugs, coming from using variables from outer scopes.
>
> True, but I'm quite happy to write pure functions without the static checking. I do not believe that the safety provided by the static checks outweighs the development cost of ensuring you have the correct qualifiers everywhere.

Maybe you don't feel the benefit because you have less bugs in multithreaded applications than you would without, but you can't really know unless you do write the same code without ? Or something like that. :o)

Anyway, I have the feeling that it's very hard to quantify the benefits of adding purity vs not having it. The benefits are both very theoretical, and practically verified in functional languages everyday. But knowing that the compiler *guarantees* certain properties and that some classes of errors cannot happen helps coding with a certain peace of mind, i.e you *know* that some bad things can't happen. So it's a little pain to satisfy the static checking of the compiler, but it's still much better than having to debug random race conditions that happen once in a while in production and are thus very hard to reproduce, and it does certainly help when you have to *ensure* that your critical code can never hang.

On 29-04-2012 16:40, Jacob Carlborg wrote:
> On 2012-04-28 20: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?
>
> * Some of the built-in properties could probably be move to a library
> solution, specially now when we have UFCS.

+1.

>
> * The with-statement isn't particular useful. Although I've started to
> use it in one of my projects just so I don't have to use fully qualified
> enum names.

It is very useful in some cases where you operate a lot on the same object.

>
> * D embedded in HTML (don't know if this is still supported)

Madness... I think it's deprecated now.

>
> * Multiple syntax for wysiwyg strings. I think the r"" syntax can be
> remove.
>
> * Do-while loops, how useful are those actually?

I use them occasionally, but it's certainly true that they are rarely useful.

>
> Then I think some features could be replaced with library solutions if D
> got some other features. For example:
>
> * foreach(_reverse)
> * synchronized
>
> These could probably be removed in favor of library solutions.
>
> void foreach (T)(T[] arr, void delegate (ref T) dg)
> {
> for (size_t i = 0; i < arr.length; i++)
> dg(arr[i]);
> }
>
> foreach ([1, 2, 3, 4], (i) { writeln(i); });
>
> The above already works today. If we can a bit syntax sugar for
> delegates and inlinable delegates we could have this:
>
> foreach ([1, 2, 3, 4] ; i) {
> writeln(i);
> }
>
> The above syntax would be very useful in other cases as well.
>
> The same could be done for "synchronized" as well. Might even be
> possible to remove the for-statement and just have "while" left.
>
> I we want get even more wild and crazy I think Scala's solution for
> operator overloading looks really good. But that would require several
> other features to work. Like:
>
> * Everything is an object (might not be needed with UFCS)
> * Everything is a method call on an object
> * Infix notation for calling any method taking one argument
> * Basically any symbol is allowed in method names
>
> That is:
>
> 1 + 2
> foo bar foo_bar
>
> Would be translated to:
>
> 1.+(2)
> foo.bar(foo_bar)
>
> That is a very general way to handle operators and let the user create
> new operators, not just overloading existing ones.
>


-- 
- Alex

On 29-04-2012 22:24, SomeDude wrote:
> On Sunday, 29 April 2012 at 18:47:11 UTC, David Nadlinger wrote:
>> On Sunday, 29 April 2012 at 18:39:49 UTC, SomeDude wrote:
>>> What's wrong with packages ?
>>
>> Nothing – this is about the »package« protection level, not packages. ;)
>>
>> David
>
> Ah ok. But I'm not sure what's wrong with the package protection level
> either, actually.

Yes, me neither. And I have found many cases in my code where using it actually makes sense and helps encapsulation.

-- 
- Alex

On 29-04-2012 22:52, Andrej Mitrovic wrote:
> 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.

I think all of the error messages you posted could need improvement. In any case, that's a compiler issue if anything.

-- 
- Alex

Le 29/04/2012 22:40, Alex Rønne Petersen a écrit :
> On 29-04-2012 00:04, H. S. Teoh wrote:
>> 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
>>
>
> Let's not forget .reverse. Why these are properties (and .dup/.idup) is
> seriously beyond me.....
>

Why they are not provided as lib but by the core language ?

On 29-04-2012 22:16, Andrej Mitrovic wrote:
> On 4/29/12, Alex Rønne Petersen<xtzgzorex@gmail.com>  wrote:
>> Next up is the issue of op-assign operations. In D, you can't do:
>>
>> obj.foo += 1;
>> obj.foo++;
>>
>> while in C#, you can (it results in a get ->  add 1 ->  set and get ->  inc
>> ->  set, etc).
>
> It's great to see another (successful) language implemented this. Do
> we have a proposal open for this somewhere?

AFAIK no.

-- 
- Alex

Le 29/04/2012 21:30, Nick Sabalausky a écrit :
> "deadalnix"<deadalnix@gmail.com>  wrote in message
> news:jnhopd$gi3$1@digitalmars.com...
>>
>>   - out arguments. We can return tuples, out argument is going backward in
>> history.
>
> You can overload on out parameters. You can't overload on return type. So
> without "out" making an optional output param would be harder to make and
> uglier to use. That could be even more of a problem if the out param in
> question is expensive to compute.
>

Good point, but it have many way to work around and shouldn't justify a feature in the core language by itself, especially if, like out parameter, it is a confusing feature.

> Also, out is nice when interfacing with C. Returning tuples wouldn't help
> here.
>

C don't have out parameters as D have. C have pointer to do kind of out parameters, and D have pointers too, this is a non issue.

On Sunday, 29 April 2012 at 20:54:11 UTC, Alex Rønne Petersen wrote:
>> - 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.
>

What's the problem ?  What prevents you to put the unit tests in other modules if you don't want to put them with the code ?