July 27, 2012
On Friday, 27 July 2012 at 02:41:21 UTC, Nick Sabalausky wrote:
> On Fri, 27 Jul 2012 04:09:36 +0200
> "Stuart" <stugol@gmx.com> wrote:
>> I can't think of ANY situation where goto would be the only viable option.
> Duff's device.

According to Wikipedia, Duff's device (about which, until just now, I knew nothing) can be implemented without goto. Then again, this might be due to "features" of C++ that are not present in D.

In any case, isn't it the job of the compiler to unroll loops? Why should the coder have to do this himself? Unless of course he's using a thin shitty wrapper over assembly language that claims falsely to be a high-level language - i.e. C.
July 27, 2012
On Friday, 27 July 2012 at 02:48:36 UTC, Jonathan M Davis wrote:
>> I'm having difficulty thinking in terms of D. It looks like C++,
>> it compiles to native code (unlike .NET), therefore I need to
>> manage memory myself... ;)
>> I'll get the hang of it eventually.
> In general, you should just let the GC do its thing.

Yeah, I know. I was just explaining how I find myself thinking in terms of C++ because the syntax (and compilation) is very similar.
July 27, 2012
On Friday, 27 July 2012 at 03:00:25 UTC, Brad Anderson wrote:
> D equivalent: iota(0, int.max, 2).map!(a => /* do something with even numbers */)();

I think you're missing the point. The purpose isn't to generate a sequence of numbers, but to illustrate how the Yield keyword is used in VB.NET. Sure, getting a sequence of numbers may be straightforward, but what about a lazy-populated list of all files on a computer? That can be done using Yield - and more importantly, WRITTEN like a normal synchronous function. Let's see you do that with map.
July 27, 2012
On Friday, 27 July 2012 at 06:36:17 UTC, Jacob Carlborg wrote:
> On 2012-07-27 02:25, Jonathan M Davis wrote:
>> scope on local variables is going to be deprecated, because it's unsafe. scope on function parameters and scope statements
> are here to stay.
> "scope" on class declarations as well.

Huh? If you deprecate scoped locals, you have to deprecate scope classes, because the latter means "must be scoped local when used". Yes?

July 27, 2012
On Friday, 27 July 2012 at 07:41:50 UTC, Simen Kjaeraas wrote:
> On Fri, 27 Jul 2012 06:36:57 +0200, Alex Rønne Petersen <alex@lycus.org> wrote:
>> Jumping over initialization isn't as problematic in D because variables are guaranteed to have a default initialization value (if not initialized to void).
> And how is that supposed to work, when you just skipped that piece of code?

A very good question.
July 27, 2012
On Friday, 27 July 2012 at 07:42:51 UTC, Nick Sabalausky wrote:
> On Fri, 27 Jul 2012 08:31:36 +0200
> Jacob Carlborg <doob@me.com> wrote:
>> Note that iterators in .NET and C++ are a bit different. .NET has language support with the "yield" keyword.
> I wonder how that works under the hood.

It's well-documented. The compiler creates an anonymous class with a state machine. It's really useful.
July 27, 2012
On Friday, 27 July 2012 at 12:56:12 UTC, Rainer Schuetze wrote:
>> Incidentally, none of that answered my original question, which is "why does VisualD crash?"
> I tried to reproduce it, but for my solutions it works. I suspect it might have to do with your window layout. You might try to remove the solution options file (.suo) and see if it still crashes. Please create a ticket here: http://www.dsource.org/projects/visuald/newticket

Yes, removing the .suo file fixed the problem. I don't know why. I will create a ticket. Would submitting my .suo file help?

>> The only other thing I don't like about VisualD is that the intellisense kinda blows. It's very hit-and-miss. Why is this?
> The intellisense part is rather unfinished. it needs full semantic analysis, and that is almost as complex as a D compiler. I'm not really sure what you mean by "Blows" or "hit-and-miss", though.

Well, it doesn't work in a lot of cases. A lot of times I'll press . or ( and get nothing at all.
July 27, 2012
On Friday, 27 July 2012 at 03:26:22 UTC, Nick Sabalausky wrote:
> I didn't think that was true in C? It's certainly true in D, anyway.

It is, C and D have more or less the same goto rules.

void a() {
        goto cool;

void main() {
        cool: ;
$ gcc goto.c
goto.c: In function a:
goto.c:2: error: label cool used but not defined

While you can still kinda sorta spaghetti in C, the fact
that it is limited to a function makes it much easier to
follow. There's only one function to look at, not the
whole program.

The requirement of a label is important too, since any
particular line of code can't be a comes-from point;
unless there is a label there, you can be pretty confident
that the line before is actually run before.

July 27, 2012
Am Fri, 27 Jul 2012 07:22:49 +0000 (UTC)
schrieb Stefan Scholl <stesch@no-spoon.de>:

> Stuart <stugol@gmx.com> wrote:
> > Why does D have GOTO? I haven't used GOTO in over a decade, because it's truly evil.
> Dogmas are evil.

I clicked through a few responses, and this one I liked most.
It feels like GOTO was stigmatized during the days when if/for/while appeared to replace its omni presence. Back than it was ok to shout and scream about every use, but today it is more likely that people who use goto, know what they are doing.

I use it in switch-case for "preprocessing", where there may be 3 cases that all end at case 3:, but case 1 and 2 need something done first. Now you can just goto case 3 at the end of 1 & 2.
Also when I have a sequence of steps to be done and some steps may jump back a few steps, I prefer labels with good names + goto, over blocks of for/while/if, which distract from the sequential nature of the code.

It's funny how I felt a bit offended by "Why does D have GOTO? […] it's truly evil." :D


July 27, 2012
On Friday, 27 July 2012 at 01:45:35 UTC, Jonathan M Davis wrote:
> It's a useful construct when used
> properly. It just shouldn't be used when there are better alternatives.

Hmm... do you have a use case besides Duff's device and porting legacy code?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16