July 27, 2012
On Friday, July 27, 2012 04:13:09 Stuart wrote:
> On Friday, 27 July 2012 at 01:54:16 UTC, Chad J wrote:
> > Stuart & other readers:
> > 
> > I just asked about this in the other thread, and Jonathan mentioned that std.typecons.scoped can be used to accomplish the same thing.  So the functionality isn't being removed; it's just being moved from the language and into the library.
> > 
> > I think this is worth mentioning so that it doesn't look like we are depriving folks of things that they had come to expect from D.
> 
> Oh, that's alright then. Although, I'd still like to know why it's unsafe. Also, is there any documentation on how to *use* the scope feature from the library? I mean, do we just "import std.typecons.scoped" and suddenly the keyword pops back into existence, or do we need to use some kind of new syntax?

We have library documentation on dlang.org:

http://dlang.org/phobos/std_typecons.html#scoped

- Jonathan M Davis
July 27, 2012
On Friday, 27 July 2012 at 02:13:19 UTC, Jonathan M Davis wrote:
>
> It's inherently unsafe. What happens if you returned a reference to foo from someFunc?

Good answer. I didn't think of that.

> scope on local variables is going away for pretty much the same reason that delete is.

Delete is going away too? Damn. Then again, I guess I'm still thinking in C++ terms. I need to stop doing that.

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.

July 27, 2012
On Friday, 27 July 2012 at 02:17:22 UTC, Jonathan M Davis wrote:
> 
> We have library documentation on dlang.org:
>
> http://dlang.org/phobos/std_typecons.html#scoped

Wow! That's a lot of information.

Better get reading it, then.

Thanks.
July 27, 2012
On Fri, 27 Jul 2012 04:09:36 +0200
"Stuart" <stugol@gmx.com> wrote:

> On Friday, 27 July 2012 at 01:45:35 UTC, Jonathan M Davis wrote:
> > Now, we have way more safe constructs for moving around in code
> > then was the case when goto was originally vilified,
> > and everyone is using those constructs rather than goto.
> > But the stigma remains and everyone is used to thinking of goto
> > as evil.
> 
> So if everyone uses these other constructs, why even provide a goto? I seriously have not needed a goto in over ten years; and the way I see it, if your program uses one, it needs to be refactored. Just my opinion.
> 
> > It's a useful construct when used properly. It just shouldn't
> > be used when
> > there are better alternatives.
> 
> I can't think of ANY situation where goto would be the only viable option. Loops, ifs, switches - these cover 100% of requirements, surely? If it really is necessary in some cases, how have I managed to avoid goto for so long? And what are these cases?


Duff's device.

Goto certainly should not be used (except for "goto case") in the vast majority of cases. And it is indeed extremely rare to find goto used in D code. Plus having it in existence doesn't really cause problems - only abusing it causes problems and but nobody really abuses goto anymore anyway. But there are some rare controlled cases (like duff's device, or porting old C code that might use it) where some low-level programmers do consider it to be useful (whether right or wrong). So it's there if for whatever reason you happen to need it, otherwise it just stays out of the way and doesn't bother anybody.

July 27, 2012
On Fri, 27 Jul 2012 04:05:48 +0200
"Stuart" <stugol@gmx.com> wrote:
> 
> Incidentally, none of that answered my original question, which is "why does VisualD crash?"
> 

You should probably ask over at wherever VisualD's site is. I don't personally use big IDEs much (I use Programmer's Notepad 2 for my D work) and in fact many of us here (though certainly not all) actually just use relatively plain highlighting text editors and the command line. So it'll probably be better to just ask the VisualD people directly.

July 27, 2012
On Friday, July 27, 2012 04:27:36 Stuart wrote:
> On Friday, 27 July 2012 at 02:13:19 UTC, Jonathan M Davis wrote:
> > It's inherently unsafe. What happens if you returned a reference to foo from someFunc?
> 
> Good answer. I didn't think of that.
> 
> > scope on local variables is going away for pretty much the same reason that delete is.
> 
> Delete is going away too? Damn. Then again, I guess I'm still thinking in C++ terms. I need to stop doing that.
> 
> 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. Then when you have portions of your code that need to be optimized, _then_ you worry about managing GC memory or using malloc and free instead or whatever it takes to make it properly efficient. Coding in a way that reduces unnecessary heap allocations is also good, but if you're worrying about when you need to free GC-allocated resources, then you're likely going about things wrong, since that's what the GC is for.

- Jonathan M Davis
July 27, 2012
On Friday, 27 July 2012 at 02:41:21 UTC, Nick Sabalausky wrote:
> Plus having it in existence doesn't really cause problems - only abusing it causes problems and but nobody
> really abuses goto anymore anyway.

goto in C and descendants is an entirely different animal
than the goto that people would abuse anyway.

The fact that it is scoped to functions and must go to
explicit labels limits the potential for abuse that made it
notorious.
July 27, 2012
On Fri, 27 Jul 2012 03:56:32 +0200
"Stuart" <stugol@gmx.com> wrote:

> On Friday, 27 July 2012 at 00:10:31 UTC, Brad Anderson wrote:
> > D uses ranges instead of iterators. You can read more about them here: http://ddili.org/ders/d.en/ranges.html
> >
> > I find ranges to be a vast improvement over iterators personally (I use iterators extensively in C++ for my job and lament not having ranges regularly).
> >
> >
> On Friday, 27 July 2012 at 00:17:21 UTC, H. S. Teoh wrote:
> > D has something far superior: ranges.
> >
> > 	http://www.informit.com/articles/printerfriendly.aspx?p=1407357&rll=1
> >
> > Even better, they are completely implemented in the library. No unnecessary language bloat just to support them.
> 
> I'm not very well up on ranges. I understand the general [1 ... 6] type of ranges, but I really don't see how custom range functions could be as useful as the Yield support in VB.NET. I mean, here's an example of an iterator in VB.NET:
> 
>     Public Function InfiniteSequence(StartValue As Int32, Step As
> Int32) As IEnumerable(Of Int32)
>        Do
>           Yield StartValue
>           StartValue += Step
>        Loop
>     End Function
> 
> Usage:
> 
>     For Each N in InfiniteSequence(2, 2)
>        ... do something with this sequence of even numbers ...
>     Next
> 
> Notice how this function is written like a synchronous loop, yet yields a lazy-initialised infinite sequence of numbers. Granted, it's not a particularly useful example, but trust me: Iterators and Yield in .NET is *really* damn useful. I would go so far as to say it was one of the language's best features.
> 
> I may be wrong, but it looks like I'd have to code a new class - not to mention several specific functions and some kind of state variable - just to simulate this functionality in D. Can anyone clarify this for me?

D can do that with either fibers or opApply. I've explored all the different approaches in this admittedly not-so-well-written article:

https://semitwist.com/articles/article/view/combine-coroutines-and-input-ranges-for-dead-simple-d-iteration

Note, however, that fibers (while far, *far* faster than
threads) are still too heavyweight to be recommended for most
generator functions (as I learned after writing that article). So if you
want a generator, you should use opApply instead of fibers or my
"InputVisitor" trick. I'd recommend using Adam's trick mentioned in the
second "Update" at the bottom of the article.

July 27, 2012
On Thu, Jul 26, 2012 at 7:56 PM, Stuart <stugol@gmx.com> wrote:

> On Friday, 27 July 2012 at 00:10:31 UTC, Brad Anderson wrote:
>
>> D uses ranges instead of iterators. You can read more about them here: http://ddili.org/ders/d.en/**ranges.html<http://ddili.org/ders/d.en/ranges.html>
>>
>> I find ranges to be a vast improvement over iterators personally (I use iterators extensively in C++ for my job and lament not having ranges regularly).
>>
>>
>>  On Friday, 27 July 2012 at 00:17:21 UTC, H. S. Teoh wrote:
>
>> D has something far superior: ranges.
>>
>>         http://www.informit.com/**articles/printerfriendly.aspx?**
>> p=1407357&rll=1<http://www.informit.com/articles/printerfriendly.aspx?p=1407357&rll=1>
>>
>> Even better, they are completely implemented in the library. No unnecessary language bloat just to support them.
>>
>
> I'm not very well up on ranges. I understand the general [1 ... 6] type of ranges, but I really don't see how custom range functions could be as useful as the Yield support in VB.NET. I mean, here's an example of an iterator in VB.NET:
>
>    Public Function InfiniteSequence(StartValue As Int32, Step As Int32) As
> IEnumerable(Of Int32)
>       Do
>          Yield StartValue
>          StartValue += Step
>       Loop
>    End Function
>
> Usage:
>
>    For Each N in InfiniteSequence(2, 2)
>       ... do something with this sequence of even numbers ...
>    Next
>
> Notice how this function is written like a synchronous loop, yet yields a lazy-initialised infinite sequence of numbers. Granted, it's not a particularly useful example, but trust me: Iterators and Yield in .NET is *really* damn useful. I would go so far as to say it was one of the language's best features.
>
> I may be wrong, but it looks like I'd have to code a new class - not to mention several specific functions and some kind of state variable - just to simulate this functionality in D. Can anyone clarify this for me?
>

D equivalent: iota(0, int.max, 2).map!(a => /* do something with even
numbers */)();


July 27, 2012
On Thu, 26 Jul 2012 17:23:53 -0700
Ali Çehreli <acehreli@yahoo.com> wrote:
>  > iterators
> 
> Here is a paper that compares different approaches:
> 
>    http://www.informit.com/articles/printerfriendly.aspx?p=1407357
> 

As great as Andrei's article is, this makes me think: We need a short article with a simple little example that demonstrates *how* D's ranges really do kick iterators' asses. Any good ideas?