On Sunday, 29 April 2012 at 17:05:19 UTC, David Nadlinger wrote:
> On Sunday, 29 April 2012 at 15:50:54 UTC, Don wrote:
>> * package. I have no idea how a failed Java experiment got incorporated into D.
>
> +1, forgot to mention that one.
>
> David

What's wrong with packages ?

On 4/29/12, Jacob Carlborg <doob@me.com> wrote:
> In principle I agree with you. But in practice this doesn't always work.
> Take this for example:
> Prints "0" and "1" as expected. If we now change "point" to a property
> like this:
> It will now print "0" and "0". This is a silently breaking change. Sure
> you can change "point" to return by reference..

This is a great point and an issue I've ran into and talked about before. The compiler really ought to try and convert a call like this:

foo.property++;
foo.property+=10;

into e.g.:
foo.property = foo.property.opAdd(1);
foo.property = foo.property.opAdd(10);

It would make for some really nice APIs if this feature was available. Otherwise I have to resort to template magic and delegate calls such as:

class Widget {
    Notify!Point pos;
    this() { pos.init(&posSet); }  // if pos changes, invoke posChange
    void posChange(ref Point newPos) { newPos.normalize(); }  // e.g.
if out of bounds
}

Unfortunately that template broke in an earlier compiler regression that I haven't noticed until recently (http://d.puremagic.com/issues/show_bug.cgi?id=7991)

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

Andrej Mitrovic:

>>   - »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.
>
> I think those are already deprecated? Or they're about to be anyway.

I have asked for it, but currently there are no plans in deprecating them, please vote if you agree and you have free votes left (already 7 votes! It's a lot):

http://d.puremagic.com/issues/show_bug.cgi?id=6277

Bye,
bearophile

On 4/29/12, bearophile <bearophileHUGS@lycos.com> wrote:
> I have asked for it, but currently there are no plans in deprecating them, please vote if you agree and you have free votes left (already 7 votes! It's a lot):

Well I assumed they're on the way to deprecation when I've read this:

http://dlang.org/changelog.html#new2_058:
"Allow 1.userproperty syntax. NOTE: 1.f is no longer a float literal, add a 0."

"Timon Gehr" <timon.gehr@gmx.ch> wrote in message news:jnj92m$306m$1@digitalmars.com...
> On 04/29/2012 08:35 AM, Nick Sabalausky wrote:
>
>> it's just a series of manifest
>> constants. The fact that they're grouped doesn't even have any semantic
>> consequence, as far as I'm aware.
>
> The only differences are that they don't occupy their own namespace and they don't define their own type. But non-anonymous enums are _just a bunch of manifest constants_ as well!

No, they're not. Non-anon enums *contain* a bunch of manifest constants. But what non-anon enums *are* is a type. Anon enums are not a type at all. I think that's a significant difference.

Note this is in stark contrast to:

- Classes: Anonymous or not, it's still a type.
- Functions: Anonymous or not, it's still *not* a type.

The syntaxes we have for anon enums and non-anon enums makes them *look* like they're basically the same thing, just with/without a name, but that's not actually the case.

Of course, my biggest issue by far is with the name "enum". Non-anon enums can reasonably be thought of as enumerations (except for bitfields, but I think those should be handled differently from enums anyway). But anon-enums are just plain not enumerations, period. If we weren't calling them all "enum", then I would have much, much less problem with the syntax we have. And yea, I get the whole "What's in a name?", but "enum" is just a colossally *terrible* name for this. It's worse than when "immutable" was called "invariant".

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

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

David

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

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

I do agree that maybe we should *prefer* returning tuples over out params (at least once we kill off the useless comma operator and have a concise built-in syntax for tuples), but I don't think tuples are enough to replace out entirely.

On 04/29/2012 08:08 PM, Manu wrote:
> On 29 April 2012 18:50, Don <nospam@nospam.com
> <mailto:nospam@nospam.com>> wrote:
>
>     On 28.04.2012 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?
>
>
>     * The >>> operator, which does nothing except introduce bugs (It
>     does NOT perform an unsigned shift).
>
>
> What does it do? I use this all over the place, I assumed it worked...
> maybe I have bugs?
>

It does work, but it behaves in unexpected ways for narrow signed integers (short/byte) because it sign-extends them before shifting. It works fine with int/uint/long/ulong.


>
>     * Most of the __traits are useless and redundant.
>
>
> Which traits are useless and redundant? I'm actually finding the set is
> incomplete, and there are some missing (parameter list introspection,
> current scope/object identification, current module/package)

+1.

"F i L" <witte2008@gmail.com> wrote in message news:oakvbobsvtawtdcasglk@forum.dlang.org...
>
> Other things that would be cool:
>
> - static foreach

We sort of do:

// Unrolled at compile-time
foreach(T; TypeTuple!(int, string, BigInt))
{
    ...
}

I'm not sure that's valid outside a function, though.