On 2012-04-30 09:32, simendsjo wrote:

> 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

"This project is currently on ice in favor of porting orbit from D1 to D2 and continue its implemention.
Orbit will cover the same featureset as dsss and much more."

BTW, Orbit is already ported to D2.

> And it seems this might be related too:
> https://github.com/dbuilder-developers/dbuilder

This seems to be a build tool and not a package manager.

> Getting orbit up and running would have been great.


-- 
/Jacob Carlborg

On Monday, 30 April 2012 at 07:49:48 UTC, simendsjo wrote:
>
> I use it to "fake" object initializers from C#: http://msdn.microsoft.com/en-us/library/bb384062.aspx
> A feature I love in C# and would like to see in D.

Ooh, nice - care to share?

On Mon, 30 Apr 2012 11:31:49 +0200, John Chapman <johnch_atms@hotmail.com> wrote:

> On Monday, 30 April 2012 at 07:49:48 UTC, simendsjo wrote:
>>
>> I use it to "fake" object initializers from C#: http://msdn.microsoft.com/en-us/library/bb384062.aspx
>> A feature I love in C# and would like to see in D.
>
> Ooh, nice - care to share?

Basically just
auto c = new C; with(c) {
  field = value;
}

On 30.04.2012 13:21, SomeDude wrote:
> On Monday, 30 April 2012 at 07:37:13 UTC, Dmitry Olshansky wrote:
>>>
>>
>> Right, nowdays any compiler is either smart enough or a dead meat that
>> nobody uses.
>> P.S. dmd is kind of work in progress ;)
>
> A smart enough compiler would understand natural language and turn it
> into efficient assembly. :o)

Yeah, unless it decides to take a vacation. :)
Or you know such a compiler may have a lot of more interesting things to do so our mundane ideas may just have to wait for a while.

-- 
Dmitry Olshansky

On Monday, 30 April 2012 at 03:16:57 UTC, Alex Rønne Petersen wrote:
>
> The problem with D's unit test support is that it doesn't integrate well into real world build processes. I usually have debug and release configurations, and that's it. No test configuration; not only does that over-complicate things, but it also isn't really useful. I want my unit testing to be exhaustive; i.e. I want to test my code in debug and release builds, because those are the builds people are going to be using. Not a test build.
>
> So, this means that writing unit tests inline is a no-go because that would require either always building with unit tests in all configurations (madness) or having a test configuration (see above).
>
> Given the above, I've resorted to having a "tester" executable which links in all libraries in my project and tests every module. This means that I have to write my unit tests inside this helper executable, making much of the gain in D's unittest blocks go away.
>
> And no, the fact that I link libraries into the helper executable doesn't mean that I can just write the unit tests in the libraries in the first place. Doing so would require building them twice: Once for the normal build and once for the "tester" executable.
>

OK, that makes sense. What a test framework could do, although it's kind of ugly, is first copy the unittest() sections into separate test files, compile them and then link with the tested module code.
You would keep the advantage of having test code close to source code, and still compile the real code without -unittest switch.

> (And yes, build times matter when your project gets large enough, even in D.)

Just for information, how big is your project (how many files), and how long does a full build take ? I have no idea how fast the compiler really is (is it GDC or DMD you are using ?).

On Sunday, 29 April 2012 at 19:30:24 UTC, Nick Sabalausky wrote:
> "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.

Well the functional way would be to use Option types as in:
Tuple!(int, Option!ExpensiveType) foobar(bool cond) {
  if (cond) return tuple(0, newExpensiveType());
  else return tuple(-1, Option.None);
}

I prefer the above as it's more readable IMO (we REALLY should get a much better tuple syntax though ....)
I do agree that this won't work when interfacing with C but IMO we shouldn't design D around limitations of C.

On Monday, 30 April 2012 at 07:52:10 UTC, Dmitry Olshansky wrote:
> On 30.04.2012 10:55, Jonathan M Davis wrote:
>> On Monday, April 30, 2012 01:41:45 bearophile wrote:
>>> 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?
>>
>> Honestly, I don't think that you _can_ take much from this thread other than
>> the fact that pretty _every_ feature is wanted and used by someone, even if
>> other people hate it. Pretty much every feature listed as undesirable by
>> someone was listed as desirable by someone else.
>
> foreach_reverse, comma operator, etc.

These are the only two I can count that nobody felt eager to keep. Yet these are only nitpicks. Also, both work, so the benefit of removing them vs breaking code... I would be glad to remove the current comma operator if its semantic was changed for something like this:
http://forum.dlang.org/post/ajdmseliewbindkkoxxj@forum.dlang.org
But I don't think it's on the table.

So I believe the conclusion several of us have reached is, that it's more important to make things that already exist work as intended without ugly corner cases and hacks.

Meta comment: C++ is the spawn of the devil so I don't accept anything related to c++ as a valid argument.

On Sunday, 29 April 2012 at 20:09:34 UTC, Alex Rønne Petersen wrote:
[...]
>>
>> 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.
>
> Yeah, we tried that in C++. It sucked.

See meta comment above.

>
> The reason it works for many functional languages is that they have even more terse syntax than D. It would suck to make foreach a function in D.
>

D wants to support functional programming. That means we should provide whatever is necessary to write functional style code including foreach methods. IF D can't properly implement a FP foreach method (And IMO it *can*) than we have failed.

>>>
>>>> * version - this does not belong in a programming language. Git
>>>> is a much better solution.
>>>>
>>>
>>> So you'd maintain a git branch for every OS if there is some small
>>> part that is OS-dependent? I don't think that is a better approach at
>>> all.
>>
>> It is far better than having a pile of #ifdef styled spaghetti code.
>> I'd expect to have all the OS specific code encapsulated separately anyway,
>> not spread around the code base. Which is the current recommended way of
>> using
>> versions anyway. The inevitable conclusion would be to either use a
>> version management system like git or have separate implementation
>> modules for platform specific code and use the build tool to implement
>> the logic of select the modules to include in the build.
>
> Yeah, we tried that in C and C++. It sucked. See: Autotools.
>

see meta comment above.
The fact that you used a horribly designed language with a horrible mess of a "build tool" made out of shell scripts IIRC is not an indication that the language should include build-tool functionality.

On 30 April 2012 10:32, Don Clugston <dac@nospam.com> wrote:

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

O_O
Is that intentional? Or is it... a bug?
I smiled when I saw >>> in the language, I appreciate its presence. It's
not necessary, but it cuts down on some ugly explicit casting (which
theoretically makes generic code simpler).

On 30 April 2012 10:39, Jacob Carlborg <doob@me.com> wrote:

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


That's the only thing I was aware it did ;) .. are there other uses?