On 12.05.2012 14:39, Manu wrote:
> On 12 May 2012 13:13, Jonathan M Davis <jmdavisProg@gmx.com
> <mailto:jmdavisProg@gmx.com>> wrote:
>
>     So, basically it's just the issue with neither ref nor const ref taking
>     lvalues.
>
>
> And the local references, and the bug.
>
>     If you duplicate the functions (or use auto ref if they're templated
>     functions), then it's not an issue.
>
>
> Yes it is. Passing by value is NOT passing by reference, it's a totally
> different operation. And what about non-const ref?
> 'in ref' would be very nice if it worked. It would basically replace
> 'const ref'.
>
>     It sucks to have to duplicate stuff, but
>     ref works just fine as long as you don't assume that it's going to
>     allow you to
>     pass rvalues to it.
>
>
> Well there's the bugs we've seen in optimised codegen.
> Duplicating with non-ref is not a solution. It's not even a workaround.
> The only workaround is to receive a pointer, which ruins all those cases
> in terms of syntax anyway.
>
>     Personally, I almost always just have functions take
>     structs by value, so it's a non-issue except for stuff like
>     opEquals, which
>     requires const ref (for at least one overload anyway).
>
>
> Well I think it's safe to say most people pass data structs by
> reference. If I saw someone pass a struct by val, I'd consider it a
> bug/typo and fix it.

Brr... most ranges are structs. And yes, they are passed by value (rightfully so).


-- 
Dmitry Olshansky

On Saturday, May 12, 2012 15:17:22 Manu wrote:
> On 12 May 2012 14:03, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> > On Saturday, May 12, 2012 13:39:54 Manu wrote:
> > > Awesome, although it doesn't end there. Local references are also very important.
> > 
> > Never going to happen. Walter doesn't like them (they also cause issues
> > with
> > the proposal to let ref take rvalues in D IMHO), but I don't remember the
> > details. Regardless, I'd be shocked if they were ever introduced into D.
> 
> So what's the work around then?
> Using pointers pollute your usage with pointer assignment problems,
> and leads to many redundant instances of &, *, and parentheses all over the
> place.
> 
> Another scenario to consider:
> given: ref X someFunc();
> 
> ref X t = someFunc(); // fail
> 
> Without ref locals, there is no way to hold a local reference to something
> returned by a function, which defeats the purpose...
> And if ref is not a type constructor, auto and templates will never work
> properly either.

I believe that you can do it with a pointer.

auto t = &someFunc();

And as long as you don't try to increment the pointer, it's @safe. It doesn't even require different semantics when calling member functions, unlike C++ (though you'd still have to dereference it if you want to copy it, so the code would still differ somewhat from what you want in terms of syntax).

Regardless, unfortunately, I don't remember why Walter doesn't want ref local variables. You'd have to get him to explain that. I just remember that he doesn't want them and I don't think that it wasn't really up for discussion. Maybe you can find an argument to convince him. I don't know. But from what I recall, there isn't much chance of that.

> Well, while I'm sure that your use cases are very important and may be
> 
> > normal
> > in your industry, I don't think that they're normal in the programming
> > world
> > in general.
> 
> I've never met a C++ programmer (other than yourself apparently) that
> doesn't pass structs/classes by ref.
> That's generally considered absurd. And if you want evidence, just look at
> the STL, Boost, or any other C++ library you care to pick.

C++ is not D. The semantics of passing arguments are not the same (thanks primary to postblit vs copy constructors). D creates fewer copies than C++. And actually, with C++'s move constructors, as I understand it, the advice is to no longer use const& for passing objects because it screws up the compiler's ability to optimize out temporaries (and the C++11 situation is much closer to D's situation than C++98 was).

But regardless, I was never advocating that you _always_ pass structs by value. I was pointing out that for smaller structs (those with only a few members), it generally works just fine - except maybe in cases where you're worrying about absolutely every CPU cycle.

- Jonathan M Davis

"SomeDude" <lovelydear@mailmetrash.com> wrote in message news:icvpcsajlyvsubowpqxo@forum.dlang.org...
>
> Indeed, and Timon forgot the best feature of IDEs for bytecode compilers imho: they compile in the background, so that errors are detected while you type. There is no annoying "write-correct" cycle as compile-time errors are shown in real time. That's a *huge* productivity boost.

I find the sluggish text-editing that inevitably implies to be MUCH more destructive to my productivity than an occasional few seconds compiling after I'm done typing. The former interferes with my mental processes, the latter does not.

"Manu" <turkeyman@gmail.com> wrote in message news:mailman.647.1336819289.24740.digitalmars-d@puremagic.com...
> On 12 May 2012 13:13, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
>
>> They just have to sort out how to avoid the issues that C++
>> has due to allow const& to take rvalues (which is why const ref in D
>> doesn't
>> currently take rvalues). So, there's a good chance that the situation
>> will
>> improve considerably sometime soon.
>>
>
> What are these issues I keep hearing about? I'm not aware of any
> fundamental problem with ref in C++...
> Can you show an example of the problem the design is trying to avoid?
>

There was a big discussion of recently on the dmd beta mailing list . One of Andrei's posts there explained it all. (Sorry, I don't have a link handy ATM. Shouldn't be too hard to find, though.)

"Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.657.1336847061.24740.digitalmars-d@puremagic.com...
>
> Regardless, unfortunately, I don't remember why Walter doesn't want ref
> local
> variables. You'd have to get him to explain that. I just remember that he
> doesn't want them and I don't think that it wasn't really up for
> discussion.
> Maybe you can find an argument to convince him. I don't know. But from
> what I
> recall, there isn't much chance of that.
>

IIRC, this was also explained in the big discussion on the dmd beta mailing list.

On 5/11/12 10:38 PM, Ary Manzana wrote:
> Add a binarySearch(range, object) method that does all of that?
>
> I mean, I don't want to write more than a single line of code to do a
> binarySearch...

assumeSorted(range).contains(object)

is still one line, safer, and IMHO more self-explanatory.

Andrei

On Friday, 11 May 2012 at 19:02:50 UTC, Philippe Sigaud wrote:
> On Fri, May 11, 2012 at 8:55 PM, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:
>
>> If newbies had the proper introduction to the concept of templates
>> (instead of being dunked in the deep end of the pool with signature
>> constraints that use templates, nested templates, etc., with no prior
>> warning), they wouldn't have such a hard time with them.
>
> I wrote a tutorial on templates, any comment is welcome:
>
> https://github.com/PhilippeSigaud/D-templates-tutorial
>
> Direct link to the pdf:
>
> https://github.com/PhilippeSigaud/D-templates-tutorial/blob/master/dtemplates.pdf?raw=true
>
> I need to get back to it, I was side-tracked by other projects and
> still have things to add to the doc.
>
>
> Philippe

Philippe, I have already went through that draft 3/4 times.

Even though I am in the D world for a decade, I always learn
something new about D templates and related.

Amazing work! Thank you!

On 5/12/2012 1:13 AM, Ary Manzana wrote:
> On 5/12/12 12:14 PM, Nick Sabalausky wrote:
>> "DUE FOR TOMORROW"?!?
>>
>> That's NOT FUCKING ENGLISH! There IS NO "due for"!! Period!
>
> Hilarious :-)

Due-be-due-be-due! -- Sinatra

"Paulo Pinto" <pjmlp@progtools.org> wrote in message news:jojish$2cm2$1@digitalmars.com...
>
> The author of a D based PSP emulator just rewrote
> the emulator in C#, after being disappointed with D.
>
> https://github.com/soywiz/cspspemu
>
> The reasons are listed here,
>
> https://github.com/soywiz/cspspemu#created-after-4-tries
>

(Heh, now that Time Warner is no longer destroying GitHub for me and I can actually *see* that page...)

"The lack of a good IDE, the complicated structure of the D language, the horrible compilation times, caused that it taked too much time for everything, and made it impossible to refactoring the code without days or weeks of work."

That almost sounds like he's talking about some completely different D programming language. And I know it's been discussed here already, but seriously, "horrible compilation times"? What hell is he smoking?

Hmm, actually, you know what? I bet he was probably trying to do the C/C++ thing and compile one...source...file...at...a...time. THAT would certainly do it. You can easily get nearly-C++-level speeds that way. Or maybe using rebuild: even with one-at-a-time disabled, rebuild can still be pretty slow compared to say, rdmd.

LOL, *or*...He didn't say "horribly SLOW compilation times", he just said "horrible compilation times". Maybe he just hates fast compiles? Not even enough time to go grab a coffee, let alone catch a movie and dinner. ;)

On 13-05-2012 00:20, Nick Sabalausky wrote:
> "Paulo Pinto"<pjmlp@progtools.org>  wrote in message
> news:jojish$2cm2$1@digitalmars.com...
>>
>> The author of a D based PSP emulator just rewrote
>> the emulator in C#, after being disappointed with D.
>>
>> https://github.com/soywiz/cspspemu
>>
>> The reasons are listed here,
>>
>> https://github.com/soywiz/cspspemu#created-after-4-tries
>>
>
> (Heh, now that Time Warner is no longer destroying GitHub for me and I can
> actually *see* that page...)
>
> "The lack of a good IDE, the complicated structure of the D language, the
> horrible compilation times, caused that it taked too much time for
> everything, and made it impossible to refactoring the code without days or
> weeks of work."
>
> That almost sounds like he's talking about some completely different D
> programming language. And I know it's been discussed here already, but
> seriously, "horrible compilation times"? What hell is he smoking?
>
> Hmm, actually, you know what? I bet he was probably trying to do the C/C++
> thing and compile one...source...file...at...a...time. THAT would certainly
> do it. You can easily get nearly-C++-level speeds that way. Or maybe using
> rebuild: even with one-at-a-time disabled, rebuild can still be pretty slow
> compared to say, rdmd.

You know, my project consisting of 130-ish source files and 24.000-ish lines of code compiles from scratch in ~20 seconds on my machine, building one file at a time... I honestly have not managed to come up with a build system for D that is actually slow, if compared to C/C++.

>
> LOL, *or*...He didn't say "horribly SLOW compilation times", he just said
> "horrible compilation times". Maybe he just hates fast compiles? Not even
> enough time to go grab a coffee, let alone catch a movie and dinner. ;)
>
>

-- 
- Alex