On 4/9/14, 11:54 AM, Andrej Mitrovic wrote:
> On 4/9/14, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>> E succ(E value);
>> E succ(E value, E overflow) nothrow;
>> E pred(E value);
>> E pred(E value, E overflow) nothrow;
>
> Not to nitpick, but next/prev for the names is easier to understand.
> "succ" is rare, and "pred" reminds me of "predicate".
>

Good point. I was going with Pascal, perhaps not a model to follow. -- Andrei

On Saturday, 5 April 2014 at 18:47:50 UTC, Walter Bright wrote:
> On 4/5/2014 10:10 AM, Timon Gehr wrote:
>> On 04/03/2014 04:45 AM, Walter Bright wrote:
>>> On 4/2/2014 6:55 PM, Andrei Alexandrescu wrote:
>>>> A lot of them could apply to us as well.
>>>>
>>>> https://www.youtube.com/watch?v=TS1lpKBMkgg
>>>
>>>
>>> at about 44:00: "I begged them not to do them [AST macros]." :-)
>>
>> (This is a misquote.)
>
> Yeah, I should have been more accurate.
>
> In response to a question about macros & reflection:
>
> "I begged them not to, not to just export the compiler to I begged them I begged them not to do it."

Which is a very different statement.

On Tuesday, 8 April 2014 at 22:08:52 UTC, H. S. Teoh wrote:
> On Tue, Apr 08, 2014 at 09:46:51PM +0000, Meta wrote:
>> Then there's also making objects default non-null, tuple syntax,
>> qualified constructors...
>
> I dunno, default non-null objects is pretty low in my priority list, and
> tuple syntax is just icing on the cake. I think there are other things
> that are more important. (*ahem*cough*AA's*ahem* -- though admittedly
> that's more an implementation issue, not a language issue).

Default non-null is right at the top of my wish list. I tried Maybe/Option types and now I am hooked. It is amazing how one apparently small difference in a type system changes everything. Contracts are okay for now. ( assert(x !is null) )

"Bruno Medeiros" <bruno.do.medeiros+dng@gmail.com> schrieb im Newsbeitrag news:li4a40$tn2> What I'm after
> * I don't need a programming language.
> * I need a coherent set of tools for creating software. A "language" is
> incidental.
> "
>
> I totally agree. Sure, the language may be the core, and one of the most important aspects, but the rest of the tool-chain is extremely important too.
>
> I don't think everyone in the D community (and outside it too) fully stands behind this idea.

At least I do.

Let me explain:

My "life-project" is represented by 450.000 lines C++ (music-notation)
written in 14 years.
I learned to hate C++ because of its unproductivity.
I'm desparately waiting for something better.
(that's why I have been following the D development from the beginning)

BUT: The tool "VisualAssist", which I use now for a long time, is so tremendously useful, that it makes programming for me often fun and joy!!! Enjoy programming C++! Crazy, isn't it?

Crucial is at least:
- easy navigation to definitions/declarations/locations of usage
- hyper-intelligent completion (VA does a superior job)
- reasonable refactoring

Visual Assist does a perfect job in providing this level
of comfort to C++-Programmers.

I did not find anything comparable yet in the D-toolbox.

I feel D is superior to C++ in almost all fields, but if I have to
change to a half-intelligent IDE, which gives me only reduced
orientation/control/completion in a 1/2-mio-lines-project,
then it is no alternative for me.

That's why I'm still standing at the fence and watch all the exciting development from outside.

Regards
Christof Schardt

On Wednesday, April 09, 2014 14:14:21 Andrei Alexandrescu wrote:
> On 4/9/14, 11:14 AM, Jonathan M Davis wrote:
> > On Wednesday, April 09, 2014 08:38:54 Andrei Alexandrescu wrote:
> >> Too restrictive. What is a valid enum value? Would an enum flags need to ascribe a name to every possible combination?
> > 
> > Why is that too restrictive? I don't see how it even fundamentally makes sense for
> > 
> > auto result = MyEnum.a | MyEnum.b;
> > 
> > to result in a value of type MyEnum.
> 
> One wants to call a function taking such an enum. -- Andrei

But it _isn't_ going to be a valid enum value. IMHO, a function which is taking or-ed flags where those flags are enums needs to take uint or ulong or whatever the base type of the enum is and _not_ the enum type. For instance, the fact that std.socket has functions which have a SocketFlags parameter is fundamentally broken, because the values passed aren't going to be valid values of SocketFlags unless you just so happen to pass only one of them rather than or-ing multiple.

I don't see how it can be anything but broken when it's trivial to have variables of an enum type which aren't valid values for that enum type. That should require casting. And the fact that code like

MyEnumString str = MyEnumString.foo ~ " bar";

compiles is just plain awful. As it stands, we can't even vaguely rely on a variable of an enum type actually being a valid value for that type, and I think that we should be able to rely on that barring a programmer screwing it up with casts.

- Jonathan M Davis

On Thursday, 10 April 2014 at 00:40:21 UTC, Jonathan M Davis wrote:
> But it _isn't_ going to be a valid enum value. IMHO, a function which is
> taking or-ed flags where those flags are enums needs to take uint or ulong or
> whatever the base type of the enum is and _not_ the enum type. For instance,
> the fact that std.socket has functions which have a SocketFlags parameter is
> fundamentally broken, because the values passed aren't going to be valid
> values of SocketFlags unless you just so happen to pass only one of them
> rather than or-ing multiple.
>

Indeed, it is an unknown enum value. The whole problem come from the fact that we try to have one thing do two things (ie a set of value and a set of orable values).

Fairly certain the second use case can be implemented as a library and do not need language support.

On Thursday, 10 April 2014 at 02:20:10 UTC, deadalnix wrote:
> Indeed, it is an unknown enum value. The whole problem come from the fact that we try to have one thing do two things (ie a set of value and a set of orable values).
>
> Fairly certain the second use case can be implemented as a library and do not need language support.

You mean a set of values and a set of values. =)

On Wednesday, 9 April 2014 at 15:38:51 UTC, Andrei Alexandrescu wrote:
> Too restrictive. What is a valid enum value? Would an enum flags need to ascribe a name to every possible combination?

Perhaps using enum for bit flags is fundamentally incorrect and only done because there is no language support for bit flags.  If bit flags were a first-class citizen of the language with its own semantics, the proposal wouldn't be so restrictive.  Adding some bit flag language support may be one way to improve enum and the overall language semantics at the same time.

On 4/9/2014 5:39 PM, Jonathan M Davis wrote:
> On Wednesday, April 09, 2014 14:14:21 Andrei Alexandrescu wrote:
>> One wants to call a function taking such an enum. -- Andrei
>
> But it _isn't_ going to be a valid enum value. IMHO, a function which is
> taking or-ed flags where those flags are enums needs to take uint or ulong or
> whatever the base type of the enum is and _not_ the enum type.

It makes perfect sense if you think of an enum as an integral type, some values of which have names, as in the "Color" example I posted earlier.

On 4/8/14, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> There are several questions to ask ourselves.

There's another small issue with enums, you currently can't easily create new aliases to enums where you want to define aliases for both the enum name and the enum members.

For example:

-----
void take(cairo_status_t e) { }
cairo_status_t get() { return cairo_status_t.CAIRO_STATUS_SUCCESS; }

// C-style enum
enum cairo_status_t
{
    CAIRO_STATUS_SUCCESS,
    CAIRO_STATUS_NO_MEMORY,
}

// D-style enum
enum Status
{
    success = cairo_status_t.CAIRO_STATUS_SUCCESS,
    noMemory = cairo_status_t.CAIRO_STATUS_NO_MEMORY
}

void main()
{
    take(Status.success);    // ok, compiles
    Status x = get();   // error
}
-----

You could use a struct wrapper with some alias this trickery, but this would be confusing compared to a normal enum, the documentation wouldn't look right, and things like EnumMembers and other enum traits would not work on this type.