On 2012-04-29 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?

I think someone started to work on this. I have no idea what happened to it though.

-- 
/Jacob Carlborg

I don't see export as nonsense. :)

"Jonathan M Davis"  wrote in message news:mailman.137.1335762449.24740.digitalmars-d@puremagic.com...

On Monday, April 30, 2012 06:58:18 David Nadlinger wrote:
> On Monday, 30 April 2012 at 01:08:28 UTC, Jonathan M Davis wrote:
> > On Sunday, April 29, 2012 17:50:48 Don wrote:
> >> * package. I have no idea how a failed Java experiment got
> >> incorporated
> >> into D.
> >
> > Really? In some cases, it's indispensable. For instance, once
> > std.datetime has
> > been split up, it will require it, or it would have duplicate a
> > bunch of
> > implementation-specific stuff which has no business in the
> > public API.
>
> But what happens if std.datetime grows so large that you want to
> have e.g. a std.datetime.system package, the content of which is
> accessible from std.datetime.*, but not the rest of the world?
>
> This is not an artificial problem, e.g. consider Thrift, where I
> have e.g. thrift.internal.endian (predating endian stuff in
> Phobos) which is used from modules in thrift.async,
> thrift.server, and thrift.protocol, or thrift.internal.socket
> (containing some more OS abstractions than std.socket does),
> which is used from modules in thrift.async, thrift.server, and
> thrift.transport, but both are not part of the public API.
>
> The logical »package« to restrict access to would be
> »thrift.*« here, but there is no way to restrict access to
> that, I have to resort to hoping users understand that they
> should not use »thrift.internal.xyz« directly. Phobos has the
> same problem with std.internal.
>
> I think in Java this problem was the reason for »super
> packages« to be discussed which (I think, haven't followed it
> the developments closely) ended up being incorporated in the
> upcoming Module System feature.

I'm not claiming that package solves all such issues (and you do give some
good examples where it would be a problem), but not having it would make the
problem even worse. I think that this is one area though where the Windows
folks take advantage of their export nonsense and just don't export the
internal stuff.

- Jonathan M Davis 

On 2012-04-29 22:26, Alex Rønne Petersen wrote:

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

`` is better because you don't have to escape ".

-- 
/Jacob Carlborg

I would say  many of the discussion items are to be fixed in a D version "break the
world" to be done when D finally becomes famous, similar to Python 3000 plans.

Until then the focus should be in fixing the open bugs, deviations to the TDPL, and
improving available tools and frameworks.

What is the point of having a perfect systems programming language if no one uses it?

--
Paulo


"bearophile"  wrote in message news:tfbtvfccnxluzbuxofot@forum.dlang.org...

Walter:

> What's your list?

This thread now has something like 240 answers (and probably few
more will come), and despite some variability in the answers, we
have seen several recurring patterns too. So what are the
conclusions, take-home insights, and the to-do's to make
something in practice, from Walter & Andrei?

Bye,
bearophile 

On 2012-04-30 00:07, Manu wrote:
> On 29 April 2012 23:00, Alex Rønne Petersen <xtzgzorex@gmail.com
> <mailto:xtzgzorex@gmail.com>> wrote:

>     Let's get a standard package manager that we either advocate on
>     dlang.org <http://dlang.org> or include in the releases before we
>     start talking about reducing the amount of modules in Phobos.
>
>
> Oh hell yes! I have exciting dreams of something like this every other
> night ;)

I'm working on this. Unfortunately I cannot work on this full-time so basically nothing gets done.

https://github.com/jacob-carlborg/orbit/wiki/Orbit-Package-Manager-for-D
https://github.com/jacob-carlborg/orbit

-- 
/Jacob Carlborg

On 29/04/12 20:08, 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 works only for two types: int and long.
For everything else, it is identical to >>
So for short and byte, and in generic code, it's ALWAYS a bug.

On Mon, 30 Apr 2012 09:24:44 +0200, Jacob Carlborg <doob@me.com> wrote:

> On 2012-04-30 00:07, Manu wrote:
>> On 29 April 2012 23:00, Alex Rønne Petersen <xtzgzorex@gmail.com
>> <mailto:xtzgzorex@gmail.com>> wrote:
>
>>     Let's get a standard package manager that we either advocate on
>>     dlang.org <http://dlang.org> or include in the releases before we
>>     start talking about reducing the amount of modules in Phobos.
>>
>>
>> Oh hell yes! I have exciting dreams of something like this every other
>> night ;)
>
> I'm working on this. Unfortunately I cannot work on this full-time so basically nothing gets done.
>
> https://github.com/jacob-carlborg/orbit/wiki/Orbit-Package-Manager-for-D
> https://github.com/jacob-carlborg/orbit
>

Vibe.d has its own: https://github.com/rejectedsoftware/vibe.d/tree/master/source/vibe/vpm
And we have dsss: https://github.com/apriori/dsss
And it seems this might be related too: https://github.com/dbuilder-developers/dbuilder

Getting orbit up and running would have been great.

On 30.04.2012 1:54, Peter Alexander wrote:
> On Sunday, 29 April 2012 at 21:18:40 UTC, deadalnix wrote:
>> Le 29/04/2012 03:06, bearophile a écrit :
>>> 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.
>>> 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...
>>>
>>
>> This is an implementation issue and shouldn't be an argument for
>> language design.
>
> The 'sufficiently smart compiler' argument is old and invalid. Please do
> not use it.
>

Right, nowdays any compiler is either smart enough or a dead meat that nobody uses.
P.S. dmd is kind of work in progress ;)

-- 
Dmitry Olshansky

On 2012-04-30 02:40, Robert Clipsham wrote:
> On 28/04/2012 20:22, Dmitry Olshansky wrote:
>> 3. with statement (?). I kind of like it but bleh it's too boggy and it
>> doesn't seem to pull its weight. (pointers? class references? a lot of
>> stuff to go wrong) Fluent interfaces solve a good portion of its
>> benefits to be specific.
>
> My primary use case for the with() statement is with final switch:
>
> final switch(something) with(MyEnumWithAPrettyLongName)
> {
> case A: // Save repeating myself everywhere
> break;
>
> . . .
>
> }
>

That's the only thing I used the with-statement for.

-- 
/Jacob Carlborg

On 30/04/12 05:45, H. S. Teoh wrote:
> On Sun, Apr 29, 2012 at 04:40:37PM +0200, Jacob Carlborg wrote:
> [...]
>> * Do-while loops, how useful are those actually?

I grepped through the DMD source once, looking for how often Walter uses do..while. The answer: exactly zero.

>
> OK, that got me all riled up about looping constructs, and now I'm
> provoked to rant:
>
> Since the advent of structured programming, looping constructs have
> always been somewhat b0rken. Yes they worked very well, they are clean,
> powerful, gets rid of almost all cases of needing goto's, etc.. But the
> point of a loop is that *the entry point does not always correspond with
> the exit point (where the loop condition is tested)*. The problem with
> both do-loops and while-loops is that they are just straitjacketed
> versions of a more general looping construct.

Completely agree. Forth is one of the few languages which got it right.

BEGIN
....
cond WHILE
...
REPEAT