Re: DIP61: Add namespaces to D

Walter Bright newshou...@digitalmars.com wrote: On 4/26/2014 12:27 PM, Daniel Murphy wrote: We already have a feature to manage conflicts and organisation in D code - modules! True. But what D doesn't have is a global namespace. I don't propose one for D, but C++ symbols may appear in the

Re: DIP61: Add namespaces to D

Walter Bright newshou...@digitalmars.com wrote: On 4/26/2014 4:01 AM, Mike wrote: pragma(cpp_namespace, A.B) extern(C++) void f() {} This implies that it only affects the name mangling. There needs to be a scope created, too. I think that's the crucial point here. Most people that disagree

Re: LinkedIn Article to be: Why you need to start moving off C/C++ to D, now.

Araq rump...@web.de wrote: The paper focusses on RC vs tracing. My point is tracing vs copying is another tradeoff. Here is a marksweep algorithm: - Trace live objects. - For each dead object: Deallocate. Here is a copying GC: - Trace and copy live objects. - There is no deallocation

Re: LinkedIn Article to be: Why you need to start moving off C/C++ to D, now.

Araq rump...@web.de wrote: On Thursday, 17 July 2014 at 15:38:44 UTC, Tobias Müller wrote: Araq rump...@web.de wrote: The paper focusses on RC vs tracing. My point is tracing vs copying is another tradeoff. Here is a marksweep algorithm: - Trace live objects. - For each dead object:

Re: LinkedIn Article to be: Why you need to start moving off C/C++ to D, now.

Paulo Pinto pj...@progtools.org wrote: On Tuesday, 15 July 2014 at 21:11:24 UTC, John Colvin wrote: I've been wondering about this. Could the following argument be true? Situations where automatic memory management are necessary are, by definition, the situations where one cannot easily

Re: LinkedIn Article to be: Why you need to start moving off C/C++ to D, now.

deadalnix deadal...@gmail.com wrote: On Thursday, 17 July 2014 at 19:19:40 UTC, Tobias Müller wrote: 1. There is no deallocation is just plain wrong. It is actually fairly common to not deallocate and reuse the pool for later allocations. If by deallocation you mean returning the memory

Re: LinkedIn Article to be: Why you need to start moving off C/C++ to D, now.

deadalnix deadal...@gmail.com wrote: On Thursday, 17 July 2014 at 19:58:32 UTC, Tobias Müller wrote: IMO manual memory management is quite easy. In 99% of all cases ownership is clear to trivial. But maybe this is just because I usually write C++ and ownership is crucial in C++. Maybe

Re: Integer overflow and underflow semantics?

Marc Schütz schue...@gmx.net wrote: On Saturday, 19 July 2014 at 19:49:24 UTC, Ola Fosheim Grøstad wrote: On Saturday, 19 July 2014 at 08:34:39 UTC, Kagamin wrote: Can't it simply generate code as is? Seems wasteful to spend compilation time on this. Not if you want fast code, consider a

Re: Integer overflow and underflow semantics?

Marc Schütz schue...@gmx.net wrote: On Sunday, 20 July 2014 at 11:09:45 UTC, Tobias Müller wrote: Marc Schütz schue...@gmx.net wrote: On Saturday, 19 July 2014 at 19:49:24 UTC, Ola Fosheim Grøstad wrote: On Saturday, 19 July 2014 at 08:34:39 UTC, Kagamin wrote: Can't it simply generate code

Re: Software Assurance Reference Dataset

Andrew Godfrey x...@y.com wrote: 1) A function annotation that means I will call myself recursively, and when I do, I expect the tail recursion optimization. I have seen code which allocates something big on the stack and depends on the optimization. So this intent should be expressible.

Re: opCmp and opEquals woes

Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: It creates very awkward relationships between the suite of operators which is likely to break down in many logical constructs. Doesn't seem that drastic to me. I don't understand; your example is the perfect example of why opCmp==0

Re: assume, assert, enforce, @safe

Walter Bright newshou...@digitalmars.com wrote: 2. The compiler can make use of assert expressions to improve optimization, even in -release mode. I can see the benefits of that, but I consider it very dangerous. It similar to undefined behavior in C/C++. There the 'assume/assert' is implicit

Re: checkedint call removal

Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 7/30/14, 7:55 AM, Tofu Ninja wrote: On Wednesday, 30 July 2014 at 14:51:34 UTC, Andrei Alexandrescu wrote: Also, it's unclear to me what the optimizer would be supposed to do if an assumption turns out to be false. Bad... bad...

Re: checkedint call removal

Walter Bright newshou...@digitalmars.com wrote: On 7/30/2014 3:53 PM, Artur Skawina via Digitalmars-d wrote: No, with the assert definition you're proposing, it won't. It would be allowed to optimize away the bounds check. And this is just one of many problems with the assert==assume approach.

Re: checkedint call removal

Walter Bright newshou...@digitalmars.com wrote: On 7/30/2014 10:16 PM, bearophile wrote: But you have redefined assert to mean a mix of assume and assert. I haven't redefined anything. It's always been that way. It's used that way in C/C++ (see your Microsoft C++ link). Actually I cannot

Re: [OT] Microsoft filled patent applications for scoped and immutable types

Russel Winder via Digitalmars-d digitalmars-d@puremagic.com wrote: First to file not first to invent – by the corporations for the corporations. This should tell you everything you need to know about technological innovation in the USA. I think you misunderstood the first to file rule. In a

Re: Which patches/mods exists for current versions of the DMD parser?

Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com wrote: This is my take on this: I don't think a fork is a bad thing, and I think BSD/MIT style licensing increase the probability of a fork down the road compared to GPL. The payoff for forking is simply higher with a liberal license.

Re: [Semi OT] Language for Game Development talk

Walter Bright newshou...@digitalmars.com wrote: On 9/26/2014 8:21 AM, Manu via Digitalmars-d wrote: I've never used an exception before. I can't imagine a reason I would ever want to. Nothrow is your friend, then! BTW, you need exceptions if there appears in your code things like:

Re: Program logic bugs vs input/environmental errors

Walter Bright newshou...@digitalmars.com wrote: On 10/4/2014 3:30 AM, Steven Schveighoffer wrote: On 10/4/14 4:47 AM, Walter Bright wrote: On 9/29/2014 8:13 AM, Steven Schveighoffer wrote: I can think of cases where it's programmer error, and cases where it's user error. More carefully

Re: Program logic bugs vs input/environmental errors

Paolo Invernizzi paolo.invernizzi@no.address wrote: And guess it, here the buildings made by ancient romans are still up and running, while we have schools building made in the '90 that come down at every earthquake... All the bad buildings from the ancient romans already came down while the

Re: toString refactor in druntime

Walter Bright newshou...@digitalmars.com wrote: [snip] Have you ever looked at the C openssl.lib? The .h files with it are loaded with metaprogramming done with C macros. Yet I've never heard anyone complain about it. Those macros are a very common common complaint in my experience. C .h

Re: DIP69 - Implement scope for escape proof references

Walter Bright newshou...@digitalmars.com wrote: [...] and ref's can still be null in C++! AFAIK only if you dereference a NULL pointer, which is UB. So not really. [...] Tobi

Re: Improving ddoc

Joseph Rushton Wakeling via Digitalmars-d digitalmars-d@puremagic.com wrote: Three things I'm not sure about: (i) does it allow definitions of custom macros as with Ddoc (although I'm not sure how necessary that is in practice); (ii) I have a nasty feeling its @keyword markup syntax (e.g.

Re: @trust is an encapsulation method, not an escape

Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com wrote: On Friday, 6 February 2015 at 13:28:59 UTC, Steven Schveighoffer wrote: The bottom line of my reasoning is that code changes over time, by different people. Context is forgotten. It's much better to have the compiler verify you

Re: Why exceptions for error handling is so important

Walter Bright newshou...@digitalmars.com wrote: On 1/11/2015 5:06 AM, Dicebot wrote: What is your opinion of approach advertised by various functional languages and now also Rust? Where you return error code packed with actual data and can't access data without visiting error code too,

Re: Why exceptions for error handling is so important

H. S. Teoh via Digitalmars-d digitalmars-d@puremagic.com wrote: On Mon, Jan 12, 2015 at 06:06:19PM +, Tobias Müller via Digitalmars-d wrote: C#'s Dictionary has TryGetValue that returns a bool in addition to the normal indexing operator [] that throws, exactly for that reason

Re: Why exceptions for error handling is so important

H. S. Teoh via Digitalmars-d digitalmars-d@puremagic.com wrote: On Mon, Jan 12, 2015 at 05:22:26PM +, Adam D. Ruppe via Digitalmars-d wrote: I still wouldn't use them for ordinary flow as a general rule though, but I think they work well for cases where you ask a function to do

Re: Why exceptions for error handling is so important

Walter Bright newshou...@digitalmars.com wrote: On 1/11/2015 11:09 PM, Tobias Müller wrote: - Error codes are automatically ignored - Exceptions are automatically propagated IMO both are not ideal and lead to sloppy programming. Ignoring errors is of course worse than aborting where you

Re: Why exceptions for error handling is so important

weaselcat weasel...@gmail.com wrote: On Monday, 12 January 2015 at 07:09:54 UTC, Tobias Müller wrote: - Error codes are automatically ignored - Exceptions are automatically propagated IMO both are not ideal and lead to sloppy programming. Ignoring errors is of course worse than aborting

Re: A reason to choose D over Go

weaselcat weasel...@gmail.com wrote: On Sunday, 22 March 2015 at 01:24:10 UTC, Martin Nowak wrote: On Saturday, 21 March 2015 at 23:49:26 UTC, Atila Neves wrote: I actually think that there are two large categories of programmers: those like writing the same loops over and over again and

Re: [OT] Modules dropped out of C++17

ponce cont...@gam3sfrommars.fr wrote: C++'s constexpr looks broken because everything must be marked constexpre, which defeats the purpose of having compile-time code looking like runtime code. But I never had the pleasure to use it. constexpr functions are just as well runtime functions. They

Re: [OT] Modules dropped out of C++17

Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 6/9/15 12:58 AM, Kagamin wrote: Same as with @safe @nogc @nothrow @pure. No, these are attributes that change the function's type; constexpr does not. Why is that better?

Re: [OT] Modules dropped out of C++17

Kagamin s...@here.lot wrote: On Tuesday, 9 June 2015 at 10:48:22 UTC, Marc Schütz wrote: static assert() is your friend in this case The point is that in D you don't need to express ctfe guarantee at all. It just works. In other words you have no guarantee. If you want the guarantee you

Re: Future(s) for D.

Nick Sabalausky seewebsitetocontac...@semitwist.com wrote: On 06/20/2015 12:34 PM, ketmar wrote: On Sat, 20 Jun 2015 12:23:59 -0400, Nick Sabalausky wrote: let's compare numbers for php, java, ruby, js -- and D. most companies will not bet on language for which a pool of hireable developers

Re: Slice patterns in Nightly Rust

Nicholas Wilson iamthewilsona...@hotmail.com wrote: On Sunday, 21 June 2015 at 03:23:18 UTC, Dennis Ritchie wrote: Recently published documentation Nightly Rust. I saw this: https://doc.rust-lang.org/nightly/book/slice-patterns.html What do you think about this: a terrible thing or a cool

Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?

Dave whate...@whatever.com wrote: On Thursday, 11 June 2015 at 20:06:45 UTC, Kagamin wrote: On Thursday, 11 June 2015 at 18:17:01 UTC, Dave wrote: Disagree. Traditionally also handled by throwing exceptions. C# throws a Format exception if a parse fails.

Re: [dlang website] Up Arrow in library

Chris wend...@tcd.ie wrote: On Monday, 18 May 2015 at 19:22:09 UTC, Walter Bright wrote: On 5/18/2015 2:18 AM, Chris wrote: A small suggestion for the library layout (phobos etc) on dlang.org: An up arrow like on duckduckgo would be cool, i.e. as soon as you scroll down an up arrow

Re: [OT] Sharp Regrets: Top 10 Worst C# Features

Chris wend...@tcd.ie wrote: [...] As if most people were too stpid to grasp the concept that `x++` is the same as `x += 1` (which is intellectually as 'challenging' as `x++`, by the way). Because it's not. ++x is the same as x+=1, not x++. Tobi

Re: Rant after trying Rust a bit

Jonathan M Davis jmdavisp...@gmx.com wrote: trait C : A,B { } How is that any different from interfaces? You can do exactly the same thing with them. implT: A+B C for T { } ^^^ That's the important line. You can define *and implement* the trait C for *all types that already implement A

Re: Rant after trying Rust a bit

Jonathan M Davis jmdavisp...@gmx.com wrote: On a related note, while I'd noticed it on some level, I don't think that it had ever clicked for me how restrictive interfaces are before this discussion. The simple fact that you can't ask for two of them at once really reduces how reusable your

Re: Read text file fast, how?

Martin Nowak code+news.digitalm...@dawg.eu wrote: On 07/26/2015 09:04 PM, Jesse Phillips wrote: It would be better to compare with LDC or GDC to match the same backend as C++. That is a little harder since they don't have 2.068 yet. Reading a file is IO and memcpy limited, has nothing to

Re: Rant after trying Rust a bit

Walter Bright newshou...@digitalmars.com wrote: On 7/23/2015 3:12 PM, Dicebot wrote: On Thursday, 23 July 2015 at 22:10:11 UTC, H. S. Teoh wrote: OK, I jumped into the middle of this discussion so probably I'm speaking totally out of context... This is exactly one major advantage of Rust

Re: Rant after trying Rust a bit

Walter Bright newshou...@digitalmars.com wrote: I know a lot of the programming community is sold on exclusive constraints (C++ concepts, Rust traits) rather than inclusive ones (D constraints). What I don't see is a lot of experience actually using them long term. They may not turn out so

Re: Rant after trying Rust a bit

Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 7/23/15 5:07 AM, Walter Bright wrote: Turns out many constraints in Phobos are of the form (A || B), not just (A B). Agreed. And that's just scratching the surface. Serious question: how do you express in Rust that a type

Re: Rant after trying Rust a bit

jmh530 john.michael.h...@gmail.com wrote: I feel like it's hard to separate borrowing from Rust's variety of pointers ( is borrowed pointer, ~ is for unique pointer, @ is for managed pointer). That's actually very outdated information. Two of the four pointer types (,@,~ and *) were ditched

Re: Rant after trying Rust a bit

Alix Pexton alix.dot.pex...@gmail.dot.com wrote: On 25/07/2015 9:48 PM, Walter Bright wrote: Unfortunately, Bruce Eckel's seminal article on it http://www.mindview.net/Etc/Discussions/CheckedExceptions has disappeared. Eckel is not a Java code monkey, he wrote the book Thinking In Java

Re: Rant after trying Rust a bit

Walter Bright newshou...@digitalmars.com wrote: On 7/26/2015 3:44 PM, deadalnix wrote: or template code (which will blow up at instanciation time, or worse, do random shit). Um, all Rust traits do is test for a method signature match, so it compiles. It is NOT a defense against a random

Re: Rant after trying Rust a bit

Walter Bright newshou...@digitalmars.com wrote: It's also clear that traits work very well in the small, i.e. in specifications of the feature, presentation slide decks, tutorials, etc. Just like Exception Specifications did. It's the complex hierarchies where it fell apart. I'm not

Re: Rant after trying Rust a bit

Walter Bright newshou...@digitalmars.com wrote: On 7/23/2015 10:49 PM, Tobias Müller wrote: Walter Bright newshou...@digitalmars.com wrote: I know a lot of the programming community is sold on exclusive constraints (C++ concepts, Rust traits) rather than inclusive ones (D constraints). What I

Re: Rant after trying Rust a bit

Walter Bright newshou...@digitalmars.com wrote: On 7/24/2015 8:43 PM, Tofu Ninja wrote: there is just a type at the top of the tree that implements them all The one type that encompasses everything defeats the whole point of type checking, traits, concepts, etc. That's exactly my feeling

Re: Rant after trying Rust a bit

Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Once we agree on that, we figure that concepts help nobody. You keep saying that, but I cannot find an explanation. Care to elaborate or give me a pointer? Tobi

Re: Rant after trying Rust a bit

Walter Bright newshou...@digitalmars.com wrote: On 7/23/2015 12:50 PM, Tobias Müller wrote: TBH I'm very surprised about that argument, because boolean conditions with version() were dimissed for exactly that reason. I knew someone would bring that up :-) No, I do not believe it is the

Re: Rant after trying Rust a bit

Walter Bright newshou...@digitalmars.com wrote: On 7/23/2015 10:39 PM, Tobias Müller wrote: You may aus well ask How do interfaces in OO programming deal with this?. It's a good question. And the answer is, the top level function does not list every interface used by the call tree. Nested

Re: Rant after trying Rust a bit

Walter Bright newshou...@digitalmars.com wrote: BTW, you might want to remove the UTF-8 characters from your user name. Evidently, NNTP doesn't do well with them. I don't think NNTP has any problems with that. My newsreader displays it just fine. Tobi

Re: Rant after trying Rust a bit

Walter Bright newshou...@digitalmars.com wrote: They write it something like: void foo(hasPrefix t) { t.prefix(); s = cast(hasSuffix)t; if (s) bar(s); else RuntimeError(message); } That's horrible! Tobi

Re: dmd codegen improvements

Iain Buclaw via Digitalmars-d wrote: > On 5 Sep 2015 11:25 pm, "Walter Bright via Digitalmars-d" < > digitalmars-d@puremagic.com> wrote: >> >> On 9/5/2015 5:54 AM, Adam D. Ruppe wrote: >>> >>> On Saturday, 5 September 2015 at 08:15:06 UTC, Walter Bright wrote:

Re: DIP74 - where is at?

Manu via Digitalmars-d wrote: > Nothing here explains to me how it is that the compiler can do without > RC primitives that the compiler knows it is allowed to > optimise/schedule as it likes? > How does it look in rust that it is able to optimise calls to inc/dec >

Re: Implementing typestate

Ola Fosheim Grøstad wrote: > On Tuesday, 15 September 2015 at 20:34:43 UTC, Tobias Müller wrote: >>> There's a Blog post somewhere but I can't find it atm. >> >> Ok found it: > http://pcwalton.github.io/blog/2012/12/26/typestate-is-dead/ > > But that is for

Re: Implementing typestate

Tobias Müller wrote: > I think they settled for a simpler library solution using a marker type (I > think it was called Phantom type) as template parameter and then using > local shadowing to emulate mutable type state. Multiple variables with same > name but different

Re: Implementing typestate

Ola Fosheim Grøstad wrote: > On Tuesday, 15 September 2015 at 20:01:16 UTC, Meta wrote: >> [...] >> If I remember correctly Rust *did* have a typestate system very > early >> on but it was done away with in favour of the borrow > checker. > > Yeah, I've seen

Re: The Case Against Autodecode

On Sunday, 29 May 2016 at 11:25:11 UTC, Chris wrote: Unicode graphemes are not always the same as graphemes in natural (written) languages. If <é> is composed in Unicode, it is still one grapheme in a written language, not two distinct characters. However, in natural languages two characters

Re: C++17

H. S. Teoh via Digitalmars-d wrote: > [long rant] If you want to attract new programmers you should stop constantly bashing other programming languages on the public forums. This is one thing that Rust got right. Tobi

Re: C++17

H. S. Teoh via Digitalmars-d wrote: > This reminds me of the time when I wanted to make a "trivial" change to > an old C++ project of mine. This was after I had become acquianted with > D, and gotten used to built-in AA's. I noticed that C++14 finally > officially had

Re: TIOBE February 2016.... 15 ?!

Ola Fosheim Grøstad wrote: > On Wednesday, 3 February 2016 at 07:06:47 UTC, cym13 wrote: >> It's all true, D rose up 6 positions: >> http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html >> >> I don't quite know what the leading factor for that

Re: [OT] Some neat ideas from the Kotlin language

rsw0x wrote: > On Saturday, 20 February 2016 at 09:40:40 UTC, Tobias Müller > wrote: >> Yuxuan Shui wrote: >>> [...] >> >> In Rust that would be: >> >> let var : Option = ...; >> if let Some(var) = var { >> // You can use var here >> } >> >> It

Re: extern(C++, ns)

Walter Bright wrote: > Oh what the hell. I'll answer it one last time: > > 1. C++ has namespaces. They went and invented a whole 'nother thing called > modules. Evidently not even they think that modules and namespaces are the > same > thing. D has modules, C++

Re: [OT] Some neat ideas from the Kotlin language

Yuxuan Shui wrote: > Just come across Kotlin today, and found some interesting ideas > skimming through its tutorial: > > 1) Null check > > Kotlin has Optional types, suffixed with a '?'. Like 'Int?', same > as in Swift. But instead of explicitly unwrapping them (e.g. var!

Re: How my little brother try D

Jesse Phillips wrote: > Oh this was the other thing I was looking for: > > http://stackoverflow.com/a/23231073/34435 > > C#'s move doesn't work across network. That's wrong AFAIK. Tobi

Re: Females in the community.

Bruno Medeiros wrote: > On 24/03/2016 09:16, Walter Bright wrote: >> We're doing just fine with NNTP and Vladimir's forum software. > > And this is one of the reasons why I've essentially moved from D to > Rust. Yes, the forum software. It's the exact opposite

Re: Females in the community.

Walter Bright wrote: > On 3/25/2016 5:36 PM, Bruno Medeiros wrote: >> What NNTP client do you use on your phone? > > I know there's at least one available on the iphone, and of course you'd have > the option to use the DFeed web interface. > >

Re: std.xml2 (collecting features)

Dejan Lekic wrote: > If you really want to be serious about the XML package, then I > humbly believe implementing the commonly-known DOM interfaces is > a must. Luckily there is IDL available for it: > https://www.w3.org/TR/DOM-Level-2-Core/idl/dom.idl . Also, >

Re: std.xml2 (collecting features)

Adam D. Ruppe wrote: > On Wednesday, 2 March 2016 at 06:59:49 UTC, Tobias Müller wrote: >> What's the usecase of DOM outside of browser >> interoperability/scripting? The API isn't particularly nice, >> especially in languages with a rich type system. > > I find my

Re: Always false float comparisons

On Friday, 20 May 2016 at 22:22:57 UTC, Walter Bright wrote: On 5/20/2016 5:36 AM, Tobias M wrote: Still an authority, though. If we're going to use the fallacy of appeal to authority, may I present Kahan who concurrently designed the IEEE 754 spec and the x87. Actually cited this

Re: Always false float comparisons

On Friday, 20 May 2016 at 06:12:44 UTC, Walter Bright wrote: On 5/19/2016 1:26 PM, Timon Gehr wrote: Those two lines producing different results is unexpected, because you are explicitly saying that y is a double, and the first line also does implicit rounding (probably -- on all compilers and

Re: memcpy() comparison: C, Rust, and D

Walter Bright wrote: > On 2/1/2017 9:22 AM, Tobias Müller wrote: >> You wouldn't use memcpy but just assign the slices. > > I clearly made a mistake in this example. I wanted to show how a compiler > learns > things from the declaration by using a very familiar

Re: memcpy() comparison: C, Rust, and D

Walter Bright wrote: > On 2/1/2017 9:28 AM, Michael Howell wrote: >> unsafe fn copy_nonoverlapping_ref(src: , dest: T, len: usize) { >> std::ptr::copy_nonoverlapping(src, dest, len) >> } >> >> Again, it doesn't guarantee no side effects, it may guarantee that src

Re: memcpy() comparison: C, Rust, and D

Walter Bright wrote: > Rust says https://doc.rust-lang.org/1.14.0/libc/fn.memcpy.html: > > pub unsafe extern fn memcpy(dest: *mut c_void, > src: *const c_void, > n: size_t) > -> *mut

Re: memcpy() comparison: C, Rust, and D

Walter Bright wrote: > I'm not very familiar with Rust. Can you post what a Rust declaration for > memcpy > would look like with all the guarantees? You wouldn't use memcpy but just assign the slices. Assignment is always just memcpy in Rust because of

Re: memcpy() comparison: C, Rust, and D

Tobias Müller wrote: > Walter Bright > But if you still wanted a memcpy it would probably look like this: > > fn memcpy<'a, T>(dest: &'a mut [T], src: &[T]) -> &'a mut [T] No, sorry: fn memcpy<'a, T: Copy>(dest: &'a mut [T], src: &[T]) -> &'a mut [T] And mutable

Re: ADL

On Friday, 2 September 2016 at 23:51:35 UTC, Manu wrote: This pattern seems to bite me every direction I turn when trying to write range or algorithm style code. C++ has ADL, and ADL works. I've never thought about this problem in C++, or had any problems with ADL. IMO the root of this

Re: ADL

Andrei Alexandrescu wrote: > On 9/3/16 7:08 PM, Tobias M wrote: >> On Saturday, 3 September 2016 at 16:33:07 UTC, Andrei Alexandrescu wrote: >>> I see. This is a matter orthogonal to DbI - introspection should be >>> able to figure out whether a member can be found,

Re: ADL

ZombineDev wrote: > So what? C#'s generics are less flexible than C++ and D templates. > The point is that C#'s lookup does not consider only the > implemented interfaces, but also falls back to extensions > methods. If C# had ADL, > the compiler would also look for

Re: ADL

Tobias M wrote: > On Saturday, 3 September 2016 at 16:32:16 UTC, ZombineDev wrote: >> Sum is implemented in that stupid way, because unlike C++, in >> C# operators need to be implemented as static methods, so you >> can't abstract them with an interface. If they were

Re: From r/linux: Which language should i use/learn ?

Chris Wright wrote: > Okay, and D gives me sufficient tools to not leak database connections > under typical workflows. So does C#. So does Python. So does Java, these > days. The last time it's been even vaguely annoying for me was with > nodejs, thanks to callback hell,

Re: ycombinator"In my Christmas wishlist is a language ..."

Ilya Yaroshenko wrote: > This is small but pleasant proof that D can be a backend language > for high performance software. Go and Rust developers will be > happy to use D under the hood of Go/Rust API if we can propose > the best libraries. They do not against D! The

Re: proposed @noreturn attribute

Timon Gehr wrote: > [...] > What I am saying is: in a language with a bottom type, we can create a > function: > > T f(T)(Bottom b){ > return b; // assuming b converts to all types implicitly. > } > > Within the function body, b is a value of type Bottom. > We use a

Re: Checked vs unchecked exceptions

Moritz Maxeiner wrote: > [...] > Or, more succinct: You must either manually write things down the > compiler could find out in a fraction of the time via static > analysis, or cheat the system; both cases are bad code. It's not at all bad code to write things down that the

Re: Introducing Nullable Reference Types in C#. Is there hope for D, too?

Timon Gehr wrote: >> I wish there was a null >> for int types. > > AFAIU, C# will now have 'int?'. C# had 'int?' (nullable value types) for ages. The new thing is explicitly nullable classes (reference types). I'm really looking forward to use those.

Re: Sealed classes - would you want them in D?

Tobias Müller wrote: > KingJoffrey wrote: >> actually, private is default in Rust. >> >> public is default in D. >> >> also, in Rust, private is private within the module, *and* its >> descendants. >> >> I don't believe that is the case in D

Re: Sealed classes - would you want them in D?

KingJoffrey wrote: > actually, private is default in Rust. > > public is default in D. > > also, in Rust, private is private within the module, *and* its > descendants. > > I don't believe that is the case in D (someone correct me if I'm > wrong) The point is,

Re: Sealed classes - would you want them in D?

KingJoffrey wrote: > The problem is not so much D, but that C++/Java/C# programmers, > and many from other languages (Go, Rust) will expect private > to mean private...not private..depending on Well, that's not entirely true. Visibility in Rust is similar

Re: Parenthesis around if/for/while condition is not necessary

aedt wrote: > Modern languages have already > dropped this requirement (i.e. Rust, Nim) and I don't see any > reason not to do so. AFAIK the if and else branches in Rust always have to be enclosed in curly braces because of this. I don't remember the exact ambiguity though.

Re: Annoyance with new integer promotion deprecations

Nick Sabalausky (Abscissa) wrote: > On 02/19/2018 03:52 AM, Manu wrote: >> On 18 Feb. 2018 10:25 pm, "Walter Bright via Digitalmars-d" < >> digitalmars-d@puremagic.com> wrote: >> >> On 2/18/2018 7:52 PM, Nick Sabalausky (Abscissa) wrote: >> >>> Well, it's

Re: Dicebot on leaving D: It is anarchy driven development in all its glory.

H. S. Teoh wrote: > On Tue, Aug 28, 2018 at 10:20:06AM -0700, Manu via Digitalmars-d wrote: > [...] > Actually, I think C++ const is not very useful, because it guarantees > nothing. At the most, it's just a sanity checker to make sure the > programmer didn't accidentally do something dumb. But

Re: Deep nesting vs early returns

H. S. Teoh wrote: > I've had to work with code that had multiply-nested #define macros > involving `do {} while(0)`, and have hated every minute of it. Yes it's ugly but it's also the only way to define a multi-statement macro that can be used like a function. --- Tobias