On Sunday, 29 April 2012 at 20:10:20 UTC, Alex Rønne Petersen wrote:
> On 29-04-2012 01:49, SomeDude wrote:
>> [snip wall of text]
>
> C++11 has range-based for (which is basically foreach).
>
>> [snip wall of text]

This is off-topic, but in general, please try to quote only the relevant parts of the message you are replying to (you just quoted the whole long message three times in full).

David

On 29-04-2012 00:49, H. S. Teoh wrote:
> 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
>

How so? It's seemed entirely reasonable to me.

-- 
- Alex

On 29-04-2012 06:36, Andrej Mitrovic wrote:
> On 4/29/12, Timon Gehr<timon.gehr@gmx.ch>  wrote:
>> - 'in' operator returning a pointer to the element.
>
> AFAIK this is a property of how the opIn_r function is implemented,
> nothing much to do with the language itself.

I hate to nitpick and all that, but opBinaryRight!"in" actually works now. ;)

>
> But it does allow for some neat tricks, like:
>
>      int[int] hash;
>      hash[1] = 2;
>      int value = *enforce(1 in hash, new Exception("1 not in hash"));
>      assert(value == 2);
> or:
>      if (auto val = 1 in hash)
>          ...use val pointer (+ if it's a class/struct pointer you still
> have access to the dot syntax)
>      else
>          ... errors..


-- 
- Alex

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.

On 28-04-2012 22:43, H. S. Teoh wrote:
> On Sat, Apr 28, 2012 at 11:47:31AM -0700, 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.
>
> D has typedef?? Wow. And I thought I had a good grasp of D.

It "has" typedef, but it is deprecated.

>
>
>> What's your list?
>
> Comma operator.

+1.

>
> foreach_reverse.

+1.

>
> with statements. They make code hard to read, and besides you can (or
> should be able to) alias long expressions into a short identifier for
> this purpose anyway.

I don't think I agree entirely here. If you have very long sequences of statements operating on the same object, with can be very useful. That said, I recognize that the current implementation of with needs some work.

>
> The great variety of string quoting syntax, while useful, seem to need
> some cleanup and unification. Get rid of r"", `` works just fine. (Or
> vice versa, but not both.) Delimited strings and token strings may be
> possible to be unified, perhaps?

IMHO r"" is better than `` for the simple reason that typing `` is extremely annoying on non-US keyboards.

>
> It's about time octal literals went the way of the bit bucket.

I think those are already deprecated.

>
> There's probably more, I'll post them as I think of them.
>
>
> T
>


-- 
- Alex

On 28-04-2012 23:20, Adam D. Ruppe wrote:
> On Saturday, 28 April 2012 at 18:48:18 UTC, Walter Bright wrote:
>> What's your list?
>
> I think most the responses to this thread are insane.
>
> But, there is one thing I don't think D needs: new.
> I'm pretty sure it could be done in the library now
> that we have robust templates, which I think would open
> up some nice things.
>
> Suppose:
>
> module std.typecons;
> NotNull!T new(T, Args...)(Args args) {
> return assumeNotNull(core.gc.new!T(args));
> }
>
> module core.gc;
> T new(T, Args...)(Args args) {
> // implement the new we know now
> }
>
>
>
> And so on, then you could get new allocators
> just by changing which module you import new from.
>
>
>
> We could kinda sorta do it now, but it wouldn't be
> as consistent, and of course, the name "new" is unavailable.

OK, so while in general I agree that 'new' shouldn't be tied to the GC by default, I don't think your example of swapping allocators through imports is a good idea at all. The reason is simple: More often than not, it never *is* as simple as just changing an import. Some allocators use stack allocation, some use C heap allocation, some use the druntime GC, some use the libgc library, ... All of these need different treatment of the allocated memory, so I don't think there is much to be gained here.

-- 
- Alex

On 28-04-2012 23:59, 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.)
>
>
>> - 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.

I don't know of any production compilers that make significant use of such annotations in any language. These qualifiers look nice in theory, but have little practical value other than making it easier to reason about code.

I don't think they should go away, just sayin'.

(BTW, I think nothing is wrong with pure.)

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


-- 
- Alex

On 29-04-2012 01:41, Peter Alexander wrote:
> On Saturday, 28 April 2012 at 23:29:35 UTC, bearophile wrote:
>> Peter Alexander:
>>
>>> f(x) ---> x.f() is not progress in language design.
>>
>> I used to think the same. But Haskell offers "." and $ to chain
>> functions and remove parentheses, F# has the |> pipe operator. In D
>> UCFS is almost equally useful to turn nesting of function calls in a
>> more readable chain. In functional-style code this makes a lot of
>> difference, turning:
>>
>> foo(bar(copy(baz(a), spam(b))))
>>
>> Into:
>>
>> baz(a).copy(b.spam()).bar().foo()
>>
>> When I see 3+ nested parentheses I find it hard to read the
>> expression. While a chain is easy to read.
>
> What D does and what Haskell does are very different things. D has (at
> least) two types of functions: free functions and member functions. UFCS
> makes free functions look like member functions. In Haskell, $ just
> gives you a way of re-ordering precedence -- it doesn't hide anything.
>
> This matters because UFCS in D is deceitful. It makes you think the free
> function is a member function when it is not.
>
> struct Foo { void bar() {} }
> void baz(Foo f) {}
>
> Foo f;
> f.bar(); // ok
> f.baz(); // ok, looks like baz is a member function
> auto pbar = &Foo.bar; // ok
> auto pbaz = &Foo.baz; // error!
>
> IMO, D would be better with Haskell's function calling syntax (of
> course, this would require many, many other syntactical changes).
>
>
>> 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.

In my experience, pure is only hard to use in D due to the runtime and standard library not being properly annotated. I don't think anything is wrong with the language feature itself.

-- 
- Alex

On 29-04-2012 00:30, Manu wrote:
> On 29 April 2012 00:42, Peter Alexander <peter.alexander.au@gmail.com
> <mailto: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)

For shared to be useful, every function you call on/with a shared object/value must be templatized. This may be nice if most of the code you write is template-rich, but like anything else, templates are not a silver bullet.

IMHO shared is heavily biased in its design, which is bad.

-- 
- Alex

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

-- 
- Alex