On Tuesday, 5 May 2015 at 02:47:03 UTC, bitwise wrote:
On Mon, 04 May 2015 00:16:03 -0400, Jonathan M Davis via
Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote:
D will move the argument if it can rather than copying it
(e.g. if a
temporary is being passed in), which reduces the need
On Monday, 4 May 2015 at 19:45:18 UTC, Andrei Alexandrescu wrote:
On 5/4/15 12:31 PM, Jonathan M Davis wrote:
Fast parsing is definitely a killer feature of
D and the fact that std.xml botches that so badly is just
embarrassing.
To be frank what's more embarrassing is that we managed to do
On Saturday, 9 May 2015 at 00:24:45 UTC, Andrei Alexandrescu
wrote:
The issues with unittests are legit, albeit fixable. It's goofy
to run the program after unittests, and unittests should have
names that can be introspected, selected etc. I couldn't find
much merit with the rest of the
On Sunday, May 10, 2015 10:48:33 Ali Çehreli via Digitalmars-d-learn wrote:
On 05/10/2015 10:18 AM, Jack Applegame wrote:
code:
class A {
void test(int) {}
}
class B : A {
void test() {
super.test(1); // compiles
test(10); // error
}
}
On Friday, May 15, 2015 21:31:35 Manfred Nowak via Digitalmars-d-learn wrote:
The following gives:
Error: 'a += b' is not a scalar, it is a C
although UFCS should engage.
-manfred
class C{}
int main(){
void opOpAssign( string op)( C a, C b){
}
C a, b;
a+= b;
}
Overloaded
On Friday, 15 May 2015 at 18:42:31 UTC, Kagamin wrote:
Many STL types inherit from base classes, yet they are used as
value types: std::string, std::vector etc. Are there plans to
support C++ types with inheritance as proper value types in D
frontend?
Given that the inheritance they have is
On Friday, 15 May 2015 at 21:11:48 UTC, Timon Gehr wrote:
On 05/15/2015 09:44 PM, Jonathan M Davis wrote:
On Friday, 15 May 2015 at 18:42:31 UTC, Kagamin wrote:
Many STL types inherit from base classes, yet they are used
as value
types: std::string, std::vector etc. Are there plans to
support
On Thursday, May 14, 2015 02:47:22 rcorre via Digitalmars-d-learn wrote:
I've run into this situation a lot:
I have a function that returns a range (in this case, a slice of
a custom container).
In some cases, the function needs to return an empty range.
It sounded like takeNone was what I
On Wednesday, May 20, 2015 06:31:11 Mike Parker via Digitalmars-d-learn wrote:
I don't understand why this behaves as it does. Given the
following two templates:
```
void printVal(T)(T t) {
writeln(t);
}
void printVal(T : T*)(T* t) {
writeln(*t);
}
```
I find that I actually have
On Wednesday, May 20, 2015 07:36:21 Namespace via Digitalmars-d-learn wrote:
What about:
import std.stdio;
void printVal(T)(T t) {
static if (is(T : U*, U))
printVal(*t);
else
writeln(t);
}
void main() {
int x = 100;
printVal(x);
int*
On Saturday, 16 May 2015 at 09:11:46 UTC, Kagamin wrote:
Inheritance in C++ is not always for polymorphism, often it's
just functionality inheritance
Exactly, so if D support C++ classes as value types, they'd just
be declared as structs in D and no inheritance would be required.
Any
On Wednesday, May 20, 2015 19:20:19 Mike Parker via Digitalmars-d-learn wrote:
On 5/20/2015 6:35 PM, Jonathan M Davis via Digitalmars-d-learn wrote:
I'm using a fairly recent version of dmd master, and it prints out the
address for px in both cases when I compile your code. So, if it's
On Thursday, May 21, 2015 08:28:29 Saurabh Das via Digitalmars-d-learn wrote:
Am I correct in assuming that an internal error in the compiler
should be filed as a bug report?
Yes. You should never see an ICE, and the compiler should never segfault.
So, whenever you see either of those happen,
On Thursday, 4 June 2015 at 13:16:48 UTC, Steven Schveighoffer
wrote:
On 6/3/15 9:51 PM, Joakim wrote:
Your entire argument seems based on fibers moving between
threads
breaking your reactor IO model. If there was an option to
disable fibers moving or if you had to explicitly ask for a
On Thursday, June 04, 2015 18:05:32 Andrei Alexandrescu via
Digitalmars-d-announce wrote:
Also, after thinking today about the universe and everything, I
concluded that that's without a doubt the ugliest bold font created by
the human civilization.
That's a bold statement. :)
- Jonathan M
On Wednesday, 3 June 2015 at 18:34:34 UTC, Liran Zvibel wrote:
As we see, there is nothing to gain and lots to lose by moving
fibers between threads.
Given that it sounds like LLVM _can't_ implement moving fibers
(or if it can, it'll really hurt performance), I think that we
need a really
On Tuesday, 2 June 2015 at 10:29:35 UTC, Daniel Kozak wrote:
I am working on dip which will try to addressed negation of
attributes issue.
http://wiki.dlang.org/DIP79
You need to iron out what happens with attributes like
@safe/@trusted/@system or public/protected/package/private.
Simply
On Friday, 5 June 2015 at 08:36:54 UTC, Jonathan M Davis wrote:
So, maybe there's some github-specific weirdness.
Or, git-specific weirdness rather. I'm so used to saying github
that I sometimes end up saying it instead of git. :|
Though I suppose that there could be something weird going
On Friday, 5 June 2015 at 01:12:25 UTC, Andrei Alexandrescu wrote:
So this is the sixth time or so I change permissions for
http://dconf.org/2015/talks/zvibel.pdf manually. I make it
world-readable, someone within a matter of hours it becomes
world-unreadable.
Attributes and owner are fine
On Friday, 5 June 2015 at 06:42:06 UTC, Rikki Cattermole wrote:
And shouldn't the CI be doing regression testing already?
The autotester runs the unit tests that are in druntime, Phobos,
and dmd. It catches a lot of stuff and generally prevents us from
merging bad code. But it can't possibly
On Friday, 5 June 2015 at 06:00:46 UTC, Dicebot wrote:
Of many things that Rust got right, this is, in my opinion,
something they did wrong. Quick release cycles only make sense
in both bleeding edge model and with availability of excess
developer resources. No amount of planning and
On Friday, June 05, 2015 09:16:29 sigod via Digitalmars-d-announce wrote:
On Friday, 5 June 2015 at 01:52:07 UTC, Vladimir Panteleev wrote:
On Friday, 5 June 2015 at 01:48:20 UTC, Meta wrote:
How feasible is it to add code formatting for the web
interface?
Not sure what you mean. Do you
On Friday, 5 June 2015 at 11:11:15 UTC, Vladimir Panteleev wrote:
On Friday, 5 June 2015 at 08:36:54 UTC, Jonathan M Davis wrote:
It works fine for me too, though glancing around online about
file permissions in github, I'm seeing really mixed messages
on what happens with them. So, maybe
On Friday, 5 June 2015 at 11:09:27 UTC, Dicebot wrote:
By the way dub master has been broken with dmd master for ages
: https://jenkins.dicebot.lv
It usually is, which usually means that I'm forced to install a
release version of the compiler just to build dub, since I'm
almost always using
On Monday, 8 June 2015 at 19:17:03 UTC, Joakim wrote:
On Monday, 8 June 2015 at 18:57:17 UTC, ponce wrote:
I can't imagine the weird look-up rules that will be made for
a translation unit both using modules and traditional headers.
At the end of the day, another set of rules for C++ers to
On Monday, 8 June 2015 at 19:48:41 UTC, Paulo Pinto wrote:
I see a problem that having those features in C++ will reduce
the desire from companies to adopt D.
There is certainly some truth to that, but I think that it's
pretty clear that in most cases, they can't do as good a job of
it as D,
On Monday, 8 June 2015 at 20:16:53 UTC, Idan Arye wrote:
On Monday, 8 June 2015 at 20:02:11 UTC, Andrei Alexandrescu
wrote:
Walter and I are looking at ways to implement it. Here's a
baseline without static foreach - a trace function that
prints function calls before they are made:
On Sunday, 7 June 2015 at 08:59:46 UTC, Iain Buclaw wrote:
I wouldn't have thought that not moving to 2.067 would be a
hold-up (there
is nothing in that release that blocks building DDMD as it is
*now*).
The biggest problem is that releasing a ddmd which is compiled
with dmd is unacceptable,
On Monday, June 08, 2015 20:36:05 Yuxuan Shui via Digitalmars-d-learn wrote:
Is there any reasons/difficulties for not implementing named
parameters?
There is clearly a need:
http://forum.dlang.org/thread/wokfqqbexazcguffw...@forum.dlang.org#post-pxndhoskpjxvnoacajaz:40forum.dlang.org
On Monday, June 08, 2015 23:18:50 Timothee Cour via Digitalmars-d-learn wrote:
nim has both overloading and named arguments (with reordering and defaults
allowed): http://nim-lang.org/docs/tut1.html#procedures-named-arguments
and it doesn't seem to cause issues.
Is there a document / thread
On Tuesday, June 09, 2015 01:38:56 Timothee Cour via Digitalmars-d-learn wrote:
On Mon, Jun 8, 2015 at 11:32 PM, Jonathan M Davis via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
On Monday, June 08, 2015 23:18:50 Timothee Cour via Digitalmars-d-learn
wrote:
nim has both
On Friday, 5 June 2015 at 12:21:20 UTC, Dicebot wrote:
On Friday, 5 June 2015 at 12:20:06 UTC, Jonathan M Davis wrote:
On Friday, 5 June 2015 at 11:09:27 UTC, Dicebot wrote:
By the way dub master has been broken with dmd master for
ages : https://jenkins.dicebot.lv
It usually is, which
On Friday, June 05, 2015 10:19:20 sigod via Digitalmars-d-announce wrote:
On Friday, 5 June 2015 at 09:53:34 UTC, Jonathan M Davis wrote:
Remember that the forum software is just a frontend for an nntp
server and that others view the content via nntp or via the
mailing list.
This just
On Saturday, 6 June 2015 at 13:44:51 UTC, Jacob Carlborg wrote:
On 2015-06-06 08:59, Jonathan M Davis wrote:
On Saturday, 6 June 2015 at 06:16:17 UTC, Andrei Alexandrescu
wrote:
Nested functions that allocate their environment dynamically
can be
quite useful. However, oftentimes the need is to
On Saturday, 6 June 2015 at 06:16:17 UTC, Andrei Alexandrescu
wrote:
Nested functions that allocate their environment dynamically
can be quite useful. However, oftentimes the need is to convert
the code plus the data needed into an anonymous struct that
copies the state inside, similar to C++
On Friday, 5 June 2015 at 23:10:33 UTC, Andrei Alexandrescu wrote:
Take a look at
https://github.com/D-Programming-Language/dlang.org/pull/1009.
Preview: http://erdani.com/d/phobos-prerelease/
Destroy.
I think that it looks okay (on my 1920x1200 screen), but it does
look a bit fuzzy.
-
On Saturday, 6 June 2015 at 21:42:47 UTC, Andrei Alexandrescu
wrote:
https://github.com/D-Programming-Language/phobos/pull/3379
Punchline: major reduction of both total run time and memory
consumed.
Reading makefiles always gives me a headache. For those of us who
can't just glance through
On Monday, 8 June 2015 at 04:16:14 UTC, Tofu Ninja wrote:
Their are plenty of examples where you would want a constructor
to be inherited, exceptions being a good one. Currently if you
have a base class with a constructor that you want all the sub
classes to have as well, you simply have to
On Monday, 8 June 2015 at 04:22:56 UTC, Mike wrote:
On Monday, 8 June 2015 at 04:21:45 UTC, Tofu Ninja wrote:
Personally I would just be happy with a d wrapper for
something like freeimage being included.
That's what Deimos is for
(https://github.com/D-Programming-Deimos/FreeImage).
On Monday, 8 June 2015 at 06:04:23 UTC, Tofu Ninja wrote:
No its definitely not something that alot of people seem to
care about, but I always found it odd that constructors get
certain special casing like this.
I expect that it originally comes down to the fact that
constructors aren't
On Monday, 8 June 2015 at 02:39:22 UTC, Tofu Ninja wrote:
Is there any reason why constructors are not inherited? All
other methods are inherited, why not constructors?
They're not polymorphic, and it doesn't make sense to call a base
class constructor on a derived class. I think that I heard
On Wednesday, 3 June 2015 at 03:14:02 UTC, Andrei Alexandrescu
wrote:
Any takers? https://issues.dlang.org/show_bug.cgi?id=14644 --
Andrei
Wait, didn't you just give a talk about how generic programming
must go? ;)
On Wednesday, 3 June 2015 at 03:43:09 UTC, bitwise wrote:
I can't remember right now what the reasoning was for 'const
ref' not to take
rvalues in the first place. I think it was that you could
escape the reference,
but this isn't true anymore with DIP25 right?
The one to ask is Andrei. I
On Tuesday, 2 June 2015 at 18:05:20 UTC, Namespace wrote:
AFAIK Andrei wanted 'auto ref' as the syntax which accepts
both, lvalues and rvalues. That's why I'm asking if the current
behaviour for auto ref for templates should change, or not. If
not, we have (as you said) two meanings of auto
On Tuesday, 2 June 2015 at 17:54:38 UTC, Iain Buclaw wrote:
I was being deliberately quizzical because there are different
takes on
what you would call simd in the language, what set of types are
available
to you, what intrinsics are exposed (and how they are exposed),
etc.
Well, Manu would
On Tuesday, 2 June 2015 at 18:44:30 UTC, Dicebot wrote:
Is there any reason to not allow argument to be any expression
and reject non-string ones at semantic phase?
Probably just simplicity and the fact that it really doesn't make
sense to use anything other than a string literal in a
On Tuesday, 2 June 2015 at 08:23:08 UTC, Manu wrote:
Curious to know if anyone here uses Premake, or cares...?
I've never heard of premake, but having support for D in more
tools is pretty much always a good thing, and there are bound to
be some folks who really care. So, this is definitely
On Tuesday, 9 June 2015 at 17:05:19 UTC, Andrei Alexandrescu
wrote:
Please help me choose what to work on next.
Well, containers matter for almost every program, whereas
databases don't. They matter for a lot of programs, but many
programs don't have them. And we already have std.container,
On Thursday, 4 June 2015 at 14:33:39 UTC, Oleg B wrote:
Hello. I not found realization of pure format function (in
phobos it not pure) and write minimal custom realization.
https://github.com/dexset/desstdx/blob/master/source/des/stdx/pformat.d#L472
Now it works with numbers and strings, but in
On Thursday, 4 June 2015 at 08:46:50 UTC, Daniel Kozák wrote:
If I will go with !attr, there will be no way to add
compile-time
expressions to it. But if we start with attr(true) or
attr(false), it
can be easily extended to support compile-time expressions in
future.
I can see that. But I
On Thursday, 4 June 2015 at 07:14:00 UTC, Daniel Kozák wrote:
On Wed, 03 Jun 2015 14:49:31 -0700
Andrei Alexandrescu via Digitalmars-d
digitalmars-d@puremagic.com
wrote:
On 6/3/15 2:19 PM, Jonathan M Davis wrote:
Regardless, I think that attribute(boolean expression) is
the clear
On Tuesday, 9 June 2015 at 22:37:32 UTC, Andrei Alexandrescu
wrote:
On 6/9/15 3:11 PM, Jonathan M Davis wrote:
And containers are really the main place, I think, where
iterators
actually do better than ranges.
I think iterators would need to add huge value to warrant
addition. -- Andrei
I
On Tuesday, 9 June 2015 at 21:53:55 UTC, Andrei Alexandrescu
wrote:
Regarding projects that we discussed you are considering, I
suggest we focus on putting std.container in good shape and opt
for a redesign only if there are great benefits. Also, I think
we should stay with libc-based I/O.
On Tuesday, 9 June 2015 at 21:20:14 UTC, Jonathan M Davis wrote:
So, I think that it would make more sense if we std.container
were completed than to embark on std.database.
I should probably add that since we already have std.container,
doing containers next is a matter of polishing it and
On Tuesday, 9 June 2015 at 20:17:01 UTC, Daniel Kozak wrote:
Yep this is the other side of a coin :), and I agree with that.
But I do not
belive that performance and features would be on same level as
individual
connectors.
I confess that what little I've heard about ODBC, it's a terrible
On Tuesday, 9 June 2015 at 18:49:04 UTC, Brad Anderson wrote:
We also have map in the form of RedBlackTree. I think you
might be able to use RedBlackTree for a set too but I haven't
tried it.
You can, but it's a bit of a pain, because you have to keep
passing it a tuple where the value gets
On Tuesday, 9 June 2015 at 17:15:46 UTC, Dennis Ritchie wrote:
On Tuesday, 9 June 2015 at 17:12:53 UTC, Liam McSherry wrote:
I think containers would be the better option. D sorely needs
to have basics like (de)queues and stacks in the standard
library, as well as any other popular and useful
On Wednesday, 10 June 2015 at 01:21:05 UTC, weaselcat wrote:
Dozens of languages pop up and die before anyone notices them,
D has been around for what, 15 years? It's obvious that it's
not going away anytime soon.
Talking about how old D is is a bit of a funny thing. IIRC,
Walter started it
On Sunday, 7 June 2015 at 08:12:11 UTC, weaselcat wrote:
you'd think with dmd's module system achieving compiler-level
parallelism wouldn't be so difficult.
IIRC, Walter stated that he wanted to add it but decided that it
would be too much of a pain to do in C++ and is waiting for us to
On Monday, 8 June 2015 at 00:05:58 UTC, weaselcat wrote:
can we discuss the downside of making phobos huge?
I actively avoid adding phobos libs to my projects because it
bloats my binaries and increases compile times by massive
amounts.
Andrei has already stated that we are definitely going
On Sunday, 7 June 2015 at 04:30:02 UTC, Andrei Alexandrescu wrote:
[...]
This is key to scalability, too. Now, the baseline numbers were
without std.experimental.allocator. Recall the baseline time on
my laptop was 4.93s. I added allocator, boom, 5.08s - sensible
degradation. However, after
On Tuesday, 23 June 2015 at 13:52:19 UTC, Daniel N wrote:
On Tuesday, 23 June 2015 at 11:03:10 UTC, Jonathan M Davis
wrote:
Which does not generally work in D. It can in some cases, but
const is so restrictive in D that you simply cannot use it
just because you don't intend to mutate a
On Tuesday, 23 June 2015 at 19:13:43 UTC, Jeremy Powers wrote:
On Mon, Jun 22, 2015 at 8:39 PM, philippecp via Digitalmars-d
digitalmars-d@puremagic.com wrote:
I think the best approach is the following:
* Throw exceptions on debug (usability)
* Leave undefined on release (performance)
On Monday, 22 June 2015 at 21:30:45 UTC, Daniel N wrote:
On Monday, 22 June 2015 at 20:56:12 UTC, Jonathan M Davis wrote:
won't mutate the argument, but if you allow it with ref in
general, then you stand no chance of being able to look at a
function signature and deduce whether the function
On Tuesday, 23 June 2015 at 17:05:41 UTC, John Colvin wrote:
On Tuesday, 23 June 2015 at 16:27:34 UTC, Jonathan M Davis
wrote:
On Tuesday, 23 June 2015 at 13:52:19 UTC, Daniel N wrote:
On Tuesday, 23 June 2015 at 11:03:10 UTC, Jonathan M Davis
wrote:
[...]
Thus the solution cannot require
On Friday, 19 June 2015 at 14:19:49 UTC, Ivan Timokhin wrote:
On Fri, Jun 19, 2015 at 01:49:14PM +, Jonathan M Davis
wrote:
On Friday, 19 June 2015 at 13:36:22 UTC, Andrei Alexandrescu
wrote:
3. Shouldn't `front` functions be const?
Good point. Made const.
That's not necessarily a good
On Sunday, 21 June 2015 at 23:02:38 UTC, Andrei Alexandrescu
wrote:
While I work on making std.allocator better, here's some food
for thought regarding std.collection.
Consider a traditional container with reference semantics,
Java-style. Regarding changing the collection (e.g.
On Sunday, 21 June 2015 at 23:58:38 UTC, H. S. Teoh wrote:
On Sun, Jun 21, 2015 at 04:02:43PM -0700, Andrei Alexandrescu
via Digitalmars-d wrote:
3. Allow the removal but throw from the ranges if there's any
attempt to use a range following a remove.
This is also too extreme. If I'm iterating
On Monday, 22 June 2015 at 05:25:57 UTC, Walter Bright wrote:
The idea is that fun(5) would be lowered to:
auto tmp = 5;
fun(tmp);
That's not what Andrei described (though it's what I would have
expected us to do). Rather, Andrei seems to be suggesting that
having an auto ref
On Monday, 22 June 2015 at 04:11:41 UTC, Andrei Alexandrescu
wrote:
Walter and I discussed what auto ref for templates should look
like and reached the conclusion that an approach based on
lowering would be best. I added a proposed lowering to
On Monday, 22 June 2015 at 06:38:57 UTC, Andrei Alexandrescu
wrote:
On 6/21/15 11:31 PM, Andrei Alexandrescu wrote:
On 6/21/15 10:25 PM, Walter Bright wrote:
The idea is that fun(5) would be lowered to:
auto tmp = 5;
fun(tmp);
I don't think that lowering is recommended - it prolongs
On Monday, 22 June 2015 at 08:10:20 UTC, Dan Olson wrote:
Docs for isIdentical say:
Same as ==, except that positive and negative zero are not
identical,
and two NANs are identical if they have the same 'payload'.
However, it returns false for NaN's with different signbits but
same
On Thursday, 25 June 2015 at 08:04:09 UTC, kink wrote:
On Wednesday, 24 June 2015 at 23:30:53 UTC, Jonathan M Davis
wrote:
But this has _nothing_ to do with scope, and scope ref was
already rejected. The whole point of this is support having a
function accept both rvalues and lvalues, not to
On Thursday, 25 June 2015 at 08:10:06 UTC, Marc Schütz wrote:
On Wednesday, 24 June 2015 at 17:47:51 UTC, Namespace wrote:
On Wednesday, 24 June 2015 at 17:45:15 UTC, Marc Schütz wrote:
On Wednesday, 24 June 2015 at 09:54:01 UTC, Jonathan M Davis
wrote:
On Wednesday, 24 June 2015 at 09:26:49
On Thursday, 25 June 2015 at 13:35:30 UTC, Vladimir Panteleev
wrote:
On Tuesday, 23 June 2015 at 22:45:10 UTC, Vladimir Panteleev
wrote:
http://dump.thecybershadow.net/0362443dfcca30860db907e494831b79/names.diff
Rationale:
- The eager versions are called absolutePath, normalizedPath,
On Thursday, 25 June 2015 at 14:10:45 UTC, Vladimir Panteleev
wrote:
And, IMHO, this:
fileName.readText.lowerCased.detabbed.toFile(fileName.withExtension(.foo))
looks much better than this:
fileName.readText.lowerCaser.detabber.toFile(fileName.extensionSetter(.foo))
Well, I have to disagree
On Thursday, 25 June 2015 at 13:53:40 UTC, Steven Schveighoffer
wrote:
On 6/24/15 12:10 PM, Iain Buclaw wrote:
http://www.microsoft.com/en-us/server-cloud/products/windows-server-2003/
Which means that (strictly speaking), in 3 weeks time, there
will be
*no* operating system that supports
On Thursday, 25 June 2015 at 13:04:12 UTC, Vladimir Panteleev
wrote:
On Wednesday, 24 June 2015 at 05:20:38 UTC, Jonathan M Davis
wrote:
When adding lazy versions in the past, for better or worse,
we've generally gone for using nouns, whereas you're
suggesting adjectives based coming from the
On Thursday, 25 June 2015 at 18:04:49 UTC, Steven Schveighoffer
wrote:
I don't know what the right name is, but I think it should be
singular at least.
Part of the core problem is that it can be used for either
parameters or arguments - or it can simply be used in certain
places as a
On Thursday, 25 June 2015 at 21:01:39 UTC, Vladimir Panteleev
wrote:
On Tuesday, 23 June 2015 at 22:45:10 UTC, Vladimir Panteleev
wrote:
http://dump.thecybershadow.net/0362443dfcca30860db907e494831b79/names.diff
So, there is some discussion about these here already:
On Thursday, 25 June 2015 at 20:58:41 UTC, Walter Bright wrote:
On 6/25/2015 11:54 AM, Andrei Alexandrescu wrote:
Result. No stuttering please. -- Andrei
Also, consider that the mangled name includes the parent
algorithm name. Let's not make mangled names excessively large,
even if it is
On Thursday, 25 June 2015 at 20:54:38 UTC, Walter Bright wrote:
Please, no code breakage because of renaming.
Well, the whole idea behind Adam's proposal to make functions
like toLower return a struct which is a lazy range but uses alias
this to do eager allocation is to allow us to switch
On Wednesday, 24 June 2015 at 01:04:01 UTC, Adam D. Ruppe wrote:
Moreover, with this, some old code will *automatically* be
upgraded to laziness without needing to change at all too. Tell
me that doesn't at least tempt you!
I very much like this approach. I don't know that it'll work in
the
On Tuesday, 23 June 2015 at 22:58:32 UTC, Vladimir Panteleev
wrote:
On Tuesday, 23 June 2015 at 22:45:10 UTC, Vladimir Panteleev
wrote:
A rename can be proposed by creating a subthread: [...]
Rationale:
As with setExt, std.uni already contains functions called
toLower/toUpper, thus the only
On Wednesday, 24 June 2015 at 03:29:28 UTC, Walter Bright wrote:
On 6/23/2015 4:49 PM, Vladimir Panteleev wrote:
IMHO, in this case, the Lazy suffix is a distracting
technicality that doesn't
carry its weight. Am I the only one?
Nope. For the reasons you mentioned.
Agreed. It would be
On Wednesday, 24 June 2015 at 00:23:42 UTC, Timon Gehr wrote:
On 06/23/2015 03:01 AM, Andrei Alexandrescu wrote:
the perfect solution.
We might as well do it right. Why promote unnecessary template
bloat?
I'm fine with it either way, but given all of the template bloat
that auto ref
On Tuesday, 23 June 2015 at 19:13:28 UTC, bitwise wrote:
And I still think Timon's statement is untrue. There is a
reason, which is that the new auto ref syntax forces reference
parameters for all types(even primitives), where the old
template approach does not.
The old template approach
On Wednesday, 24 June 2015 at 11:12:27 UTC, John Chapman wrote:
On Wednesday, 24 June 2015 at 01:04:01 UTC, Adam D. Ruppe wrote:
The code breakage is minimal
Won't this break isSomeString? Phobos uses this everywhere.
It won't break isSomeString. isSomeString will continue to work
the
On Wednesday, 24 June 2015 at 09:26:49 UTC, Temtaime wrote:
Simply give a possibility to ref in allowing use rvalues.
That has already been rejected.
- Jonathan M Davis
On Wednesday, 24 June 2015 at 10:02:12 UTC, Namespace wrote:
On Wednesday, 24 June 2015 at 09:54:01 UTC, Jonathan M Davis
wrote:
On Wednesday, 24 June 2015 at 09:26:49 UTC, Temtaime wrote:
Simply give a possibility to ref in allowing use rvalues.
That has already been rejected.
- Jonathan M
On Wednesday, 24 June 2015 at 13:43:04 UTC, Jacob Carlborg wrote:
Can't we update isSomeString to detect this use case?
We _could_ but that would be a disaster. The whole point of
isSomeString is to test whether something is a string exactly.
The code used by a function that's overloaded
On Wednesday, 24 June 2015 at 12:15:10 UTC, Joseph Rushton
Wakeling wrote:
Hello all,
As I promised at DConf (though sadly arriving a bit later than
I'd hoped), I've submitted a PR to convert std.random to a
package:
https://github.com/D-Programming-Language/phobos/pull/3406
I'd like to ask
On Wednesday, 24 June 2015 at 13:37:35 UTC, Jacob Carlborg wrote:
On 24/06/15 07:20, Jonathan M Davis wrote:
If we want to be consistent with the likes of splitter, then
they should
be something more like lowerCaser and upperCaser (though caser
isn't
really word, and AFAIK, there is no noun
On Wednesday, 24 June 2015 at 16:39:22 UTC, kink wrote:
On Wednesday, 24 June 2015 at 11:19:04 UTC, Jonathan M Davis
wrote:
[...]
3. Add a new attribute which does what's being proposed for
auto ref for non-templated functions, in which case, we can
use the non-templated behavior with
On Wednesday, 24 June 2015 at 19:45:12 UTC, Adam D. Ruppe wrote:
On Wednesday, 24 June 2015 at 19:41:54 UTC, Freddy wrote:
I was surprised when this happened, is it a bug or a feature?
Feature, overwriting const or immutable data would violate the
promise that it never changes. Saving a
On Thursday, 25 June 2015 at 03:40:31 UTC, Adam D. Ruppe wrote:
(An interesting point here though is since alias this DOES
return a string, any duck-type checks or implicit conversion
checks will also pass what it passes... and work, it'll just
silently allocate the string. Which is no
On Friday, 19 June 2015 at 13:36:22 UTC, Andrei Alexandrescu
wrote:
3. Shouldn't `front` functions be const?
Good point. Made const.
That's not necessarily a good idea. What if the element type
can't even be used when it's const? inout might work in that
case, but in general, you have to
On Wednesday, 17 June 2015 at 19:02:27 UTC, Walter Bright wrote:
On 6/17/2015 10:33 AM, Andrei Alexandrescu wrote:
Someone left a laser pen in the room where we had DConf.
Describe it to us to
get it back. Thanks! -- Andrei
If it looks like this, it's mine.
On Monday, 22 June 2015 at 20:42:58 UTC, Daniel N wrote:
Considering we already have working 'Sealed references', why
not simply allow rvalues for plain ref?
Please, please, no. That would be horrible. ref indicates an
intention to mutate the argument, which makes no sense with
rvalues. And
On Monday, 22 June 2015 at 06:29:20 UTC, Andrei Alexandrescu
wrote:
The matter is very well understood. My point here is that
leaving it to the user to make sure which ranges are still
valid vs. not is not appropriate for D's container. -- Andrei
If we mean that we don't want undefined
701 - 800 of 4528 matches
Mail list logo
