> What's your list?

- The is expressions are confusing as hell, and it seems to me that it's serving a purpose that should be handled by __traits (which has its own set of issues in my mind, but is a solid idea)

- On the subject, as much as I love __traits(), its dumping grounds nature is problematic. It should be limited to accessing traits of types, or changed to a more representative name. It's not redundant or anything, but is prone to bloating by its design.

- I am on the version hate boat. To me, it's redundant with static if().

- as many have said, the comma operator is problematic by nature and should probably go.

I haven't been into D for very long, so I'll probably run into more stuff eventually, but that's what comes off the top of my head...

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.

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

On Sat, 28 Apr 2012 14:03:26 -0700, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:

> On Sat, Apr 28, 2012 at 09:58:02PM +0200, foobar wrote:
> [...]
>> 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.
>
> I disagree. Having a dedicated foreach construct allows the compiler to
> optimize away the delegate in certain cases. I wouldn't want to incur
> the cost of creating and passing a delegate in something as simple as
> foreach (i; 0..100), for example.
>
>
>> * enum - enum should be completely redesigned to only implement
>> what it's named after: enumerations.
>
> Actually, I rather like the enum idiom of declaring compile-time
> constants. Though it could do with a renaming to something more
> befitting.
>
>
>> * version - this does not belong in a programming language. Git
>> is a much better solution.
>
> This is an interesting idea. But using separate git branches just for
> having versioned code seems a bit like total overkill... plus a
> maintenance nightmare since you have to continue pull and merge changes
> to every porting branch every time development happens. Whereas having
> everything represented in source means that whoever writes a new feature
> is also responsible for making it work with whatever versions are
> currently out there. After-the-fact fixes are always painful.
>
>
>> * 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.
>
> I proposed a while ago that .di files should be replaced by something
> better: omit ALL function bodies, template bodies, private members,
> etc., and just keep the "real" public API in the human-readable part of
> the file. Function and template bodies should be kept in as a binary
> blob readable by the compiler (which obviously needs to know them
> otherwise it won't be able to expand templates).

I have written code that will do just that. You can check it out here: https://github.com/LightBender/dmd.git. It builds both the DRuntime and Phobos perfectly, however, the Phobos makefile has not yet been updated to generate DI files. However, Phobos uses the Druntime DI files for it's build.

> (Yes the binary blob can be reverse-engineered, but so can executables,
> so it's a moot point. We're not trying to write cryptographic security
> here, but it's nice to separate what the compiler needs to know vs. what
> the user of a library needs to know.)
>
>
>> * 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.
>
> I have to disagree here. CTFE and compile-time features is a major
> reason I like D. I argue rather that compile-time features should be
> *improved*. The current situation is good, but not quite there yet. It
> can be made better.
>
>
> T
>


-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

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

But enums aren't only used for optimization. What if you want to use a constant at compile time, as a template parameter?

On 4/29/2012 6:05 AM, q66 wrote:

>>
>> I find versions sorta neat... and they're simple enough that they don't
>> add to much bloat to the language. (Whereas if you added AND and OR to
>> them, then they start duplicating the function of static if, and that's
>> when they become redundant.)
>>
>
> They're nearly unusable now. And the syntax simply makes no sense.
>
>>
>> T
>

Someone forgot to tell me how unusable they are, because I've been using them for years. Quite sensibly.

On 29.04.2012 3:25, foobar wrote:
> On Saturday, 28 April 2012 at 20:43:38 UTC, Timon Gehr wrote:
>> On 04/28/2012 09:58 PM, foobar 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?
>>>
>>> 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).
>>
>>
>> foreach is very useful. Have you actually used D?
>>
>
> I have used D and didn't claim that foreach isn't useful.
> What I said that is that it belongs in the library, NOT the language.
>

C++ was criticized for a long time for NOT having foreach in the language. Now they have http://www2.research.att.com/~bs/C++0xFAQ.html#for. Also people were so desperate to gave it that even this http://www.boost.org/doc/libs/1_49_0/doc/html/foreach.html was considered a nice addition to boost (and still part of it).

Obviously somehow you want to go into the opposite direction. Beats me.


-- 
Dmitry Olshansky

On 29.04.2012 4:31, Jonathan M Davis wrote:
> On Sunday, April 29, 2012 01:54:35 Peter Alexander wrote:
>> On Saturday, 28 April 2012 at 23:37:14 UTC, F i L wrote:
>>> Peter Alexander wrote:
>>>> I'm serious. I don't like overloaded syntax.  foo.bar
>>>> shouldn't also mean (*foo).bar -- it causes confusion and
>>>> introduces ambiguities when either could work. Combine this
>>>> with opDispatch, UFCS and function overloading and your in for
>>>> some nasty headaches.
>>>
>>> Craziness. What could you possibly gain is there in forcing a
>>> pointer distinction at every point that it's used? We already
>>> declared the variable as a pointer, we don't need to be
>>> reminded of that fact at every line.
>>
>> It matters when you have things that imitate pointers (e.g. smart
>> pointers). Those will have their own members, separate from the
>> pointee's members, so ptr.foo could refer to the smart pointer's
>> members or the pointee's members.
>
> For better or worse, the solution for smart pointers in D would be to use
> opDispatch,

*cough* alias this *cough*

 but it _does_ still mean that the type pointed to can't have any
> of the same functions as the smart pointer (or at least, they would have to be
> called differently, since . would use opDispatch and therefore use the smart
> pointer's function), so you _do_ lose something over the ->  syntax here.
> However, the overall gain is usability probably still outweighs that. I
> wouldn't exactly have been heartbroken if ->  had been in D, but simplicity of
> not needing it can be very nice - and it can be invaluable in the case of
> templates, because then you don't have to distinguish between structs,
> pointers to structs, and classes when calling functions on them.
>
> - Jonathan M Davis


-- 
Dmitry Olshansky

Am Sat, 28 Apr 2012 15:39:49 -0400
schrieb "Nick Sabalausky" <SeeWebsiteToContactMe@semitwist.com>:

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

Madness even! AAs are soon mostly in the library and that's a good trade-off; @trusted @system needs to be there as long as there is @safe; exception handling - some people rely on it heavily. See it as the easy way to error out of a function that doesn't normally return anything and cascade up several calls, while being able to release resources in each.
I don't know about Phobos. Some batteries included are nice and help the popularity. When it comes to bindings to third party products with many alternatives, like databases, I'd say one should cut it there definitly.
I can agree on the rest.

-- 
Marco

"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote in message news:mailman.67.1335651468.24740.digitalmars-d@puremagic.com...
> 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?
>

Yea, templated code is structurally-typed (duck-typed) by default. Not a big fan of that personally, but I can live with it, and D is awesome enough that you can build nominal-typing out of it: http://www.semitwist.com/articles/EfficientAndFlexible/MultiplePages/Page5/

On 29.04.2012 5:06, bearophile wrote:
> Jonathan M Davis:
>
>> * foreach_reverse is essentially redudant at this point (not to mention
>> confusing if combined with delegates), since we have retro.
>
> retro() can't replace foreach_reverse until the front-end
> demonstrability produces asm code equally efficient.

bleh C++ doesn't have reverse loop in the language. all there is rbegin() and rend(). And this attitude reminds me of the old STL days.
What's wrong with you people? Am I back to 90s ?

> Loops _must_ be fully efficient, they are a basic language construct,
> this is very important. Even foreach() is sometimes not equally
> efficient as a for() in some cases...
>
Doesn't have to do anything with the LANGUAGE.
Yesterday I tried GDC. Damn I didn't regret it :)

>
>> * I hate C style struct initializers and would really like to see them
>> go, but
>> for reasons that I don't understand, people actually use them rather
>> than using a proper constructor call,
>
> For single structs I prefer D-style initialization.
> But take a look at this code, if you replace those C-style initializers
> with D-style, even using aliases to shorten the code to single letters,
> that data section becomes more noisy:
> http://rosettacode.org/wiki/Ray-casting_algorithm#D
>
Such code (tables) is usually generated anyway.

[snip reasonable parts ;)]


-- 
Dmitry Olshansky