On Mon, 11 Aug 2014 03:04:41 -0400, Andrew Godfrey wrote:
Reminder: The PR is ready for review:
https://github.com/D-Programming-Language/dlang.org/pull/623
Jonathan has summarized his position in the commments.
What do the rest of you think?
H. S. Teoh, Jakob, Ali, Marc, Dominikus, Chris -
y
On Fri, 01 Aug 2014 01:07:55 -0400, Jonathan M Davis
wrote:
On Thursday, 31 July 2014 at 20:49:18 UTC, Timon Gehr wrote:
On 07/31/2014 09:37 PM, Jonathan M Davis wrote:
disable contracts, turn assert(0) into a halt
instruction, and disable bounds checking in @system and @trusted code.
So, i
On Mon, 01 Sep 2014 16:06:10 -0400, Nick Sabalausky
wrote:
On 9/1/2014 3:11 PM, Russel Winder via Digitalmars-d wrote:
On Mon, 2014-09-01 at 09:43 +, monarch_dodra via Digitalmars-d
wrote:
Then again, it takes a certain kind of corporate greed to try to
put a patent on things we'd have
On Mon, 08 Sep 2014 12:57:13 -0400, Andrei Alexandrescu
wrote:
On 9/8/14, 2:10 AM, Andrej Mitrovic wrote:
On Thursday, 22 May 2014 at 17:25:30 UTC, Steven Schveighoffer wrote:
A possible path is to introduce the change, but put @monitor on
Object. This will allow all current code to compile
On Tue, 09 Sep 2014 22:13:57 -0400, Nick Sabalausky
wrote:
This is getting to be (or rather, *continuing* to be) a royal PITA:
https://github.com/rejectedsoftware/vibe.d/issues/673
I don't mean to pick on Vibe.d in particular, but can we have a solution
(that doesn't involve obscure corne
On Tue, 16 Sep 2014 15:01:17 -0400, Sean Kelly
wrote:
Yeah I haven't looked at the implementation yet either.
Currently, it's possible to set a core.sync.Mutex as an object
monitor. Would this capability be preserved? Someone mentioned
a hashtable of monitors... do we really need this? I c
On Thu, 18 Sep 2014 08:57:20 -0400, Kagamin wrote:
On Tuesday, 16 September 2014 at 00:33:47 UTC, Steven Schveighoffer
wrote:
The cost for this is tremendous. You may as well not use classes.
Looks like ldc has a separate option to turn off invariants.
That's a good thing. I'm actually th
On 9/23/14 5:17 AM, bearophile wrote:
Marc Schütz:
http://wiki.dlang.org/User:Schuetzm/scope
If a mutable argument of a function is tagged as unique, the type system
guarantees that there are no other references to it. So can a function
'foo' like this be "strongly pure"?
int[] foo(unique i
On 9/23/14 6:26 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= "
wrote:
Ok, I take it back ;-) Steven is right. It is however the case that this
function's return value would still be unique.
Yes, it could be unique. I haven't read this thread really, so I don't
know what has been proposed, but looking at
On 9/23/14 7:11 AM, bearophile wrote:
Steven Schveighoffer:
int[] foo(unique int[] a) pure {
...
I don't think so. Strong pure function optimizations would not work
for something like:
auto x = foo(a) ~ foo(a);
This is similar to:
unique x1 = foo(a);
unique x2 = foo(a);
unique x = x1 ~ x2;
On 9/23/14 12:11 PM, Sean Kelly wrote:
On Tuesday, 23 September 2014 at 15:44:19 UTC, Andrei Alexandrescu wrote:
On 9/23/14, 6:41 AM, Sean Kelly wrote:
On Tuesday, 23 September 2014 at 12:19:52 UTC, Daniel Kozak via
Digitalmars-d wrote:
I know, but I mean there is no scheduler in standard lib
On 9/24/14 6:48 PM, Meta wrote:
The following code fails under DMD 2.065:
struct Test
{
bool opBinary(string op: "is", T: typeof(null))(T val)
{
return false;
}
bool opBinaryRight(string op: "is", T: typeof(null))(T val)
{
return false;
}
}
void
On 9/26/14 6:48 AM, Dicebot wrote:
On Friday, 26 September 2014 at 01:31:06 UTC, Michel Fortin wrote:
Maybe this will be of interest to someone. D was mentioned on the
official Swift Blog today:
Swift borrows a clever feature from the D language: these identifiers
expand to the location of the
On 9/26/14 12:15 PM, David Nadlinger wrote:
As Walter mentioned in a recent pull request discussion [1], the first
formal deprecation protocol we came up with for language changes looked
something like this:
1. remove from documentation
2. warning
3. deprecation
4. error
(The "remove from docum
I wanted to bring this over from D.learn, because I've never seen this
before, and it's an interesting solution to creating a property without
much boilerplate.
So here it is:
class Foo
{
union
{
private int _a; // accessible only in this module
public const int a; // accessi
On 9/26/14 6:32 PM, H. S. Teoh via Digitalmars-d wrote:
Does the compiler infer it as @safe, though?
Hm... good point, I'm not sure if unions are considered @safe. But I
think that would be a decent enhancement request if not.
-Steve
On 9/26/14 8:58 PM, H. S. Teoh via Digitalmars-d wrote:
On Fri, Sep 26, 2014 at 07:32:49PM -0400, Steven Schveighoffer via
Digitalmars-d wrote:
On 9/26/14 6:32 PM, H. S. Teoh via Digitalmars-d wrote:
Does the compiler infer it as @safe, though?
Hm... good point, I'm not sure if union
On 9/26/14 9:26 PM, H. S. Teoh via Digitalmars-d wrote:
Not a bad start. Though I do note that *declaring* an unsafe union
(according to the above definitions) is currently allowed in @safe code
by the compiler, but attempts to access a union member that overlaps
with a pointer is rejected.
It
On 9/27/14 7:15 PM, Walter Bright wrote:
When I say "They are NOT for debugging programs", I mean they are NOT
for debugging programs.
Library code often cannot make that choice. The issue with exceptions
vs. errors is that often you don't know where the input comes from.
e.g.:
auto f = Fi
On 9/27/14 3:45 AM, Daniel Murphy wrote:
"H. S. Teoh via Digitalmars-d" wrote in message
news:mailman.1799.1411796077.5783.digitalmar...@puremagic.com...
Argh, looks like another incompletely-implemented part of the compiler:
void fun() @safe {
union U {
int p;
int* q;
}
U u;
u.p++; // compi
On 9/27/14 9:52 PM, Walter Bright wrote:
On 9/27/2014 6:24 PM, Steven Schveighoffer wrote:
On 9/27/14 7:15 PM, Walter Bright wrote:
When I say "They are NOT for debugging programs", I mean they are NOT
for debugging programs.
Library code often cannot make that choice.
The issue with excepti
On 9/28/14 5:01 AM, Jacob Carlborg wrote:
On 2014-09-28 03:24, Steven Schveighoffer wrote:
Library code often cannot make that choice. The issue with exceptions
vs. errors is that often you don't know where the input comes from.
e.g.:
auto f = File(someInternalStringThatIsCorrupted) -> error
On 9/29/14 7:53 AM, Walter Bright wrote:
On 9/29/2014 4:47 AM, Steven Schveighoffer wrote:
On 9/27/14 9:52 PM, Walter Bright wrote:
If the app is concerned about invalid filenames as bugs, you should
scrub the filenames first. I.e. the interface is defined improperly if
the code confuses a prog
On 9/29/14 7:54 AM, Walter Bright wrote:
On 9/29/2014 4:51 AM, Steven Schveighoffer wrote:
What about:
File f;
f.open(null);
Is that an environmental error or User error?
Passing invalid arguments to a function is a programming bug.
That throws an exception. My point exactly.
-Steve
On 9/29/14 10:48 AM, Jacob Carlborg wrote:
On 29/09/14 13:51, Steven Schveighoffer wrote:
That makes no sense. The opening of the file is subject to issues with
the filesystem, which means they may be environmental or user errors,
not programming errors. But that doesn't mean the opening of the
On 9/29/14 10:32 AM, Atila Neves wrote:
So somehow I missed that for template functions the attributes can be
inferred. From what I can tell it has to do with having the body
available. But when not using .di files, why can't it be done for
regular functions?
There was a push to do it for ctors
On 9/29/14 2:43 PM, Jeremy Powers via Digitalmars-d wrote:
On Mon, Sep 29, 2014 at 8:13 AM, Steven Schveighoffer via Digitalmars-d
mailto:digitalmars-d@puremagic.com>> wrote:
My entire point is, it doesn't matter what is expected or what is
treated as "correct."
On 9/29/14 3:44 PM, Jeremy Powers via Digitalmars-d wrote:
On Mon, Sep 29, 2014 at 12:28 PM, Sean Kelly via Digitalmars-d
mailto:digitalmars-d@puremagic.com>> wrote:
Checked exceptions are good in theory but they failed utterly in
Java. I'm not interested in seeing them in D.
I've hea
On 9/30/14 9:42 AM, Dicebot wrote:
There is one issue I have encountered during CDGC porting I may need
advice with.
Consider this simple snippet:
```
import core.memory;
void main()
{
ubyte[] result;
result.length = 4096;
assert(GC.sizeOf(result.ptr) > 0);
}
``
Assertion passes
On 9/30/14 10:24 AM, Dicebot wrote:
On Tuesday, 30 September 2014 at 14:01:17 UTC, Steven Schveighoffer wrote:
Assertion passes with D1/Tango runtime but fails with current D2
runtime. This happens because `result.ptr` is not actually a pointer
returned by gc_qalloc from array reallocation, but
On 9/30/14 12:01 PM, Dicebot wrote:
I think it should be possible. That way actual block size will be simply
considered a bit smaller and extending happen before reserved space is
hit. But of course I have only a very vague knowledge of druntime
ackquired while porting cdgc so may need to think
On 9/30/14 1:23 PM, Sean Kelly wrote:
(except for the
definition of the APPENDABLE BlkAttr, which really should be
defined externally and within the user-reserved range of the
bitfield instead of the GC-reserved range, but I digress...)
The APPENDABLE bit was added as a solution to avoid havin
On 9/30/14 2:19 PM, Sean Kelly wrote:
On Tuesday, 30 September 2014 at 17:51:18 UTC, Steven
Schveighoffer wrote:
On 9/30/14 1:23 PM, Sean Kelly wrote:
(except for the
definition of the APPENDABLE BlkAttr, which really should be
defined externally and within the user-reserved range of the
bitfi
On 10/1/14 9:47 AM, Bruno Medeiros wrote:
On 29/09/2014 19:58, Steven Schveighoffer wrote:
Any uncaught exceptions are BY DEFINITION programming errors.
Not necessarily.
For some applications (for example simple console apps), you can
consider the D runtime's default exception handler to be an
On 10/1/14 10:36 AM, Bruno Medeiros wrote:
On 01/10/2014 14:55, Steven Schveighoffer wrote:
On 10/1/14 9:47 AM, Bruno Medeiros wrote:
On 29/09/2014 19:58, Steven Schveighoffer wrote:
Any uncaught exceptions are BY DEFINITION programming errors.
Not necessarily.
For some applications (for exa
On 10/1/14 11:00 AM, Andrej Mitrovic via Digitalmars-d wrote:
On 10/1/14, Steven Schveighoffer via Digitalmars-d
wrote:
No, this is lazy/incorrect coding. You don't want your user to see an
indecipherable stack trace on purpose.
So when they file a bug report are you going to also ask
On 10/1/14 11:53 AM, Marco Leise wrote:
Am Wed, 01 Oct 2014 15:05:53 +
schrieb "Robert burner Schadek" :
On Wednesday, 1 October 2014 at 14:24:52 UTC, Marco Leise wrote:
Am Wed, 01 Oct 2014 12:49:29 +
schrieb "Robert burner Schadek" :
maybe I should add a disableGetSysTime switch
C
On 10/1/14 3:24 PM, Paolo Invernizzi wrote:
On Wednesday, 1 October 2014 at 14:46:50 UTC, Steven Schveighoffer wrote:
On 10/1/14 10:36 AM, Bruno Medeiros wrote:
This is a grey area that I think reasonable people
can correctly call a bug if they so wish, despite the intentions of
the developer.
On 10/1/14 3:27 PM, Jacob Carlborg wrote:
On 2014-09-29 17:13, Steven Schveighoffer wrote:
Is it? I can think of cases where it's programmer error, and cases where
it's user error.
When would it be a user error?
./progThatExpectsFilename ""
-Steve
On 10/2/14 2:45 AM, Jacob Carlborg wrote:
On 01/10/14 21:57, Steven Schveighoffer wrote:
./progThatExpectsFilename ""
-Steve
It's the developer's responsibility to make sure a value like that never
reaches the "File" constructor. That is, the developer of the
"progThatExpectsFilename" applic
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 design the interfaces if programmer error and input error
are conflated.
You mean more carefully desig
On 10/3/14 1:40 PM, Sean Kelly wrote:
Setting aside exceptions for the moment, one thing I've realized about
errors is that in most cases, an API has no idea how important its
proper function is to the application writer.
This is the thing I have been arguing. Inside a library, the idea of
in
On 10/4/14 2:45 PM, Shammah Chancellor wrote:
int main()
{
scope(exit) return 0;
assert(false, "whoops!");
}
The above smells to me like it should be invalid. Specifically, the
scope(exit) line by itself.
If you want to catch and not propagate an error, you need to use
try/catch
On 10/8/14 4:10 PM, Andrei Alexandrescu wrote:
On 10/8/14, 1:01 PM, Andrei Alexandrescu wrote:
That's a bummer. Can we get the compiler to remove the "if (__ctfe)"
code after semantic checking?
Or would "static if (__ctfe)" work? -- Andrei
Please don't ask me to explain why, because I sti
On 10/9/14 4:50 AM, Martin Nowak wrote:
Kenji just proposed a slightly controversial pull request so I want to
reach out for more people to discuss it's tradeoffs.
It's about deprecating function qualifiers on the left hand side of a
function.
So instead of
const int foo();
you'd should wri
On 10/9/14 10:37 PM, Walter Bright wrote:
For functions, const-as-storage-class applies to the function symbol.
And if it is misused, the compiler will very likely complain about a
mismatched type.
Can you demonstrate this? I hate to see D reject a unanimously wanted
improvement on something
On 10/10/14 9:53 AM, ketmar via Digitalmars-d wrote:
On Fri, 10 Oct 2014 09:42:14 -0400
Steven Schveighoffer via Digitalmars-d
wrote:
Really, what you are saying here is, the unanimous opinion of the
die-hard very dedicated D community is worthless compared to the
opinion of a hypothetical
On 10/10/14 1:09 PM, IgorStepanov wrote:
I've created DIP for my pull request.
DIP: http://wiki.dlang.org/DIP66
PR: https://github.com/D-Programming-Language/dmd/pull/3998
Please, comment it.
Hm... not sure you need a DIP.
From page 231 of TDPL: "A class could introduce any number of alias
th
On 10/10/14 11:15 AM, Martin Nowak wrote:
As this is more about stating a clear preference than deprecating the
old syntax let me propose a compromise.
- adding RHS rule to D's style guide http://dlang.org/dstyle.html
with an explanation what the storage class function thing does
- change a
On 10/10/14 2:17 PM, Andrei Alexandrescu wrote:
On 10/10/14, 10:31 AM, Steven Schveighoffer wrote:
On 10/10/14 1:09 PM, IgorStepanov wrote:
I've created DIP for my pull request.
DIP: http://wiki.dlang.org/DIP66
PR: https://github.com/D-Programming-Language/dmd/pull/3998
Please, comment it.
Hm
On 10/10/14 1:09 PM, IgorStepanov wrote:
I've created DIP for my pull request.
DIP: http://wiki.dlang.org/DIP66
PR: https://github.com/D-Programming-Language/dmd/pull/3998
Please, comment it.
This part:
void test()
{
C c;
int i = c; //Error: c.a.i vs c.b.i
}
stati
On 10/10/14 4:25 PM, Brad Roberts via Digitalmars-d wrote:
On 10/10/2014 1:05 PM, market via Digitalmars-d wrote:
On Friday, 10 October 2014 at 19:14:50 UTC, ketmar via
Digitalmars-d wrote:
On Fri, 10 Oct 2014 18:14:28 +
market via Digitalmars-d wrote:
please just go. please
(smiles) yo
On 10/10/14 5:15 PM, IgorStepanov wrote:
On Friday, 10 October 2014 at 20:47:45 UTC, Steven Schveighoffer wrote:
On 10/10/14 1:09 PM, IgorStepanov wrote:
I've created DIP for my pull request.
DIP: http://wiki.dlang.org/DIP66
PR: https://github.com/D-Programming-Language/dmd/pull/3998
Please, c
On 10/10/14 6:10 PM, IgorStepanov wrote:
On Friday, 10 October 2014 at 21:26:49 UTC, Steven Schveighoffer wrote:
An example:
foo(T)(T t) if(is(T : int))
{
someFuncThatTakesInt(t);
}
foo(T)(T t) if(!is(T : int) && is(T.shadow : int))
{
someFuncThatTakesInt(t.shadow);
}
struct A
{
in
On 10/12/14 7:16 PM, IgorStepanov wrote:
On Sunday, 12 October 2014 at 23:02:13 UTC, Steven Schveighoffer wrote:
On 10/10/14 6:10 PM, IgorStepanov wrote:
You can write foo(c.shadow); This isn't hard.
Ok, I understood you, let's listen to what others say
Right, you can get around it.
But th
On 10/13/14 2:50 PM, Walter Bright wrote:
On 10/13/2014 1:53 AM, Peter Alexander wrote:
Looks like Bjarne has proposed UFCS for C++
http://isocpp.org/files/papers/N4174.pdf
No mention of D though...
https://www.reddit.com/r/programming/comments/2j3kr4/proposal_for_unified_call_syntax_for_c_x
On 10/14/14 11:34 AM, Jesse Phillips wrote:
On Monday, 13 October 2014 at 18:50:52 UTC, Walter Bright wrote:
On 10/13/2014 1:53 AM, Peter Alexander wrote:
Looks like Bjarne has proposed UFCS for C++
http://isocpp.org/files/papers/N4174.pdf
No mention of D though...
https://www.reddit.com/r/
On 10/16/14 4:21 AM, Atila Neves wrote:
Same here. I've been thinking of a DIP for a while, just haven't had
time to put it together.
Atila
On Wednesday, 15 October 2014 at 17:29:35 UTC, Trass3r wrote:
http://youtu.be/qwXq5MqY2ZA?t=33m57s
I wish we had diagnostics like that in D.
It would
On 10/17/14 10:13 AM, monarch_dodra wrote:
My personal feeling (IMO):
- Consuming, adapting, producing data: Ranges win hands down.
- Managing, shuffling or inserting elements in a container: To be
honest, I prefer iterators.
Dcollections solves this.
-Steve
On 10/19/14 3:23 PM, Brad Roberts via Digitalmars-d wrote:
Yes, the email queue running was indeed not running. I've kicked it and
will look into why it wasn't doing its job.
Ah, I wondered why a bunch of emails for notifications from last week
just came through :)
-Steve
Currently, if you write something like this:
debug = x;
It's like you passed -debug=x on the command line. However, this seems
quite scary. It means that you are debugging ALL THE TIME, with any
debug(x) statements.
Does this make sense? Note that debug disables pure checking, which can
be
On 10/21/14 12:02 PM, Gary Willoughby wrote:
On Tuesday, 21 October 2014 at 15:45:55 UTC, Steven Schveighoffer wrote:
Currently, if you write something like this:
debug = x;
In code? Like this:
void main()
{
debug = x;
// now in debug mode even though not specified on the CLI?
}
On 10/21/14 3:24 PM, Walter Bright wrote:
On 10/21/2014 12:15 PM, Gary Willoughby wrote:
On Tuesday, 21 October 2014 at 17:25:37 UTC, Steven Schveighoffer
wrote:
Yep, you can just turn off purity when it gets in the way.
-Steve
Please raise a ticket for this.
That was done deliberately - i
On 10/22/14 7:23 AM, Marco Leise wrote:
Am Tue, 21 Oct 2014 22:33:02 -0400
schrieb Steven Schveighoffer :
On 10/21/14 3:24 PM, Walter Bright wrote:
On 10/21/2014 12:15 PM, Gary Willoughby wrote:
On Tuesday, 21 October 2014 at 17:25:37 UTC, Steven Schveighoffer
wrote:
Yep, you can just turn o
On 10/22/14 4:15 PM, Walter Bright wrote:
On 10/22/2014 1:04 PM, Jonathan M Davis wrote:
Yeah, being able to just enable the debug blocks from within the code
like
that seems questionable to me and has nothing to do with debug blocks
disabling pure functions. It just makes for a nastier side eff
On 10/23/14 2:40 PM, Daniel Murphy wrote:
"Steven Schveighoffer" wrote in message
news:m2avtc$15e3$1...@digitalmars.com...
I think there is a problem though. What if you leave your debug in by
accident? Now your pure code isn't so pure, and you have no idea.
What if you leave any other form
On 10/23/14 3:31 PM, Walter Bright wrote:
On 10/23/2014 11:40 AM, Daniel Murphy wrote:
"Steven Schveighoffer" wrote in message
news:m2avtc$15e3$1...@digitalmars.com...
I think there is a problem though. What if you leave your debug in by
accident? Now your pure code isn't so pure, and you have
On 10/24/14 9:08 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= "
wrote:
On Friday, 24 October 2014 at 12:45:21 UTC, Steven Schveighoffer wrote:
On 10/23/14 3:31 PM, Walter Bright wrote:
On 10/23/2014 11:40 AM, Daniel Murphy wrote:
"Steven Schveighoffer" wrote in message
news:m2avtc$15e3$1...@digitalmars
On 10/22/14 1:17 AM, Domingo Alvarez Duarte wrote:
Let's talk about libraries now, there is some silly things like
associative array not having a "clear/lenght=0" way to reset it, and
people sugest create templates that does:
foreach(string key; aa.keys) aa.remove(key);
Annoying...
https://g
On 10/26/14 3:15 AM, Dicebot wrote:
I use this pattern somewhar often:
version(unittest)
{
debug = ExtraCostlySanityChecks;
}
My proposal covers this, it would still be fine:
http://forum.dlang.org/post/m2avtc$15e3$1...@digitalmars.com
-Steve
On 10/27/14 2:45 PM, Daniel Murphy wrote:
"Benjamin Thaut" wrote in message news:m2m3j2$ciu$1...@digitalmars.com...
They wouldn't get any uglier than they already are, because the
current toString functions within druntime also can't use std.format.
An example would be to toString function of
On 10/27/14 4:24 PM, ketmar via Digitalmars-d wrote:
On Mon, 27 Oct 2014 15:20:24 -0400
Steven Schveighoffer via Digitalmars-d
wrote:
Might I suggest a helper that takes a sink and a variadic list of
strings, and outputs those strings to the sink in order.
hehe. simple CTFE writef seems to
On 10/27/14 6:02 PM, ketmar via Digitalmars-d wrote:
On Mon, 27 Oct 2014 17:04:55 -0400
Steven Schveighoffer via Digitalmars-d
wrote:
I think this is overkill for this purpose. We need something simple
to save a few lines of code.
18KB (even less) module which consists mostly of functional
On 10/27/14 8:01 PM, Manu via Digitalmars-d wrote:
28 October 2014 04:40, Benjamin Thaut via Digitalmars-d
wrote:
Am 27.10.2014 11:07, schrieb Daniel Murphy:
"Benjamin Thaut" wrote in message news:m2kt16$2566$1...@digitalmars.com...
I'm planning on doing a pull request for druntime which
On 10/28/14 9:41 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
" wrote:
On Tuesday, 28 October 2014 at 08:15:58 UTC, Russel Winder via
Digitalmars-d wrote:
parent.send(result)
or:
send(parent, result)
as being idiomatic D code?
I cannot speak for idioms, but this is a good example of ho
On 10/28/14 10:56 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
" wrote:
On Tuesday, 28 October 2014 at 14:04:35 UTC, Steven Schveighoffer wrote:
I think it means, send result to parent. Isn't this what you said?
I had to run out the door and hit enter too early… :P
On the larger question, I thi
On 10/28/14 1:09 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
" wrote:
On Tuesday, 28 October 2014 at 16:02:03 UTC, Steven Schveighoffer wrote:
I don't think recipient.send(mail) is that unintuitive. It's how I
would visualize it from a contact application for instance.
sender.send(mail) ?
Consi
On 10/28/14 3:28 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
" wrote:
On Tuesday, 28 October 2014 at 17:44:36 UTC, Steven Schveighoffer wrote:
But parent is not the actual object, it's a *mailbox* of that object,
or a reference. In essence, you are saying "use this recipient record
to send a messa
On 10/28/14 7:06 PM, Manu via Digitalmars-d wrote:
On 28 October 2014 22:51, Steven Schveighoffer via Digitalmars-d
wrote:
On 10/27/14 8:01 PM, Manu via Digitalmars-d wrote:
28 October 2014 04:40, Benjamin Thaut via Digitalmars-d
wrote:
Am 27.10.2014 11:07, schrieb Daniel Murphy
On 10/29/14 6:03 AM, Kagamin wrote:
struct Sink
{
char[] buff;
void delegate(in char[]) sink;
void write(in char[] s)
{
auto len=min(s.length,buff.length);
buff[0..len]=s[0..len];
buff=buff[len..$];
const s1=s[len..$];
if(s1.length)sink(s1);
On 10/30/14 11:54 AM, Kagamin wrote:
On Thursday, 30 October 2014 at 15:32:30 UTC, Steven Schveighoffer wrote:
This would require sink to write the buffer before it's first call,
since you don't track that.
That's delegated to the sink delegate.
Keep in mind, sink delegate is not a singly im
On 10/30/14 2:53 PM, Jonathan Marler wrote:
Before we start ripping apart our existing APIs, can we show that the
performance is really going to be so bad? I know virtual calls have a
bad reputation, but I hate to make these choices absent real data.
For instance, D's underlying i/o system uses
On 10/31/14 4:40 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= "
wrote:
On Thursday, 30 October 2014 at 20:15:36 UTC, Steven Schveighoffer wrote:
I think the above result is deceptive, and the test isn't very useful.
The RuntimeString toString isn't a very interesting data point -- it's
simply a single str
On 11/1/14 8:04 AM, ketmar via Digitalmars-d wrote:
On Sat, 01 Nov 2014 11:55:53 +
anonymous via Digitalmars-d wrote:
On Saturday, 1 November 2014 at 11:50:34 UTC, ketmar via
Digitalmars-d wrote:
this *IS* a bug. either compiler should error on this, or it
shouldn't
modify random memory.
On 11/1/14 10:44 AM, Iain Buclaw via Digitalmars-d wrote:
On 1 November 2014 14:19, ketmar via Digitalmars-d
wrote:
On Sat, 1 Nov 2014 13:56:49 +
Iain Buclaw via Digitalmars-d wrote:
if such assigns will be forbidden for any arrays... this is even worse.
"what? your shiny language can't
On 10/31/14 4:50 PM, Jonathan Marler wrote:
I wrote a Windows CE app to run on our printers here at HP to test what
the Microsoft ARM compiler does with virtual function calls. I had to
do an operation with a global volatile variable to prevent the compiler
from inlining the non-virtual functio
On 11/1/14 9:30 AM, Manu via Digitalmars-d wrote:
On 31 October 2014 01:30, Steven Schveighoffer via Digitalmars-d
Sorry, I meant future *D supported* platforms, not future not-yet-existing
platforms.
I'm not sure what you mean. I've used D on current and existing games
c
On 10/31/14 3:04 PM, Walter Bright wrote:
On 10/27/2014 12:42 AM, Benjamin Thaut wrote:
I'm planning on doing a pull request for druntime which rewrites every
toString
function within druntime to use the new sink signature. That way
druntime would
cause a lot less allocations which end up beeing
On 10/31/14 3:07 PM, H. S. Teoh via Digitalmars-d wrote:
On Fri, Oct 31, 2014 at 12:04:24PM -0700, Walter Bright via Digitalmars-d wrote:
On 10/27/2014 12:42 AM, Benjamin Thaut wrote:
I'm planning on doing a pull request for druntime which rewrites
every toString function within druntime to use
On 10/31/14 5:01 PM, Walter Bright wrote:
On 10/31/2014 12:07 PM, H. S. Teoh via Digitalmars-d wrote:
On Fri, Oct 31, 2014 at 12:04:24PM -0700, Walter Bright via
Digitalmars-d wrote:
On 10/27/2014 12:42 AM, Benjamin Thaut wrote:
I'm planning on doing a pull request for druntime which rewrites
On 11/3/14 4:37 PM, Walter Bright wrote:
On 11/3/2014 9:36 AM, Tobias Müller wrote:
Presenting OpenSSL as a case for good interface design is a crime by
itself!
Not at all. I presented it as an example of a C library that has a
metaprogramming interface, but that interface has not prevented bu
On 11/3/14 4:40 PM, Walter Bright wrote:
On 11/3/2014 8:09 AM, Steven Schveighoffer wrote:
It is a huge difference to say EVERYONE who implements toString will
take any
templated type that purports to be an output range, vs giving one case
to handle.
All an output range is is a type with a 'pu
On 11/3/14 8:09 PM, Walter Bright wrote:
On 11/3/2014 2:28 PM, Steven Schveighoffer wrote:
I had a very nasty experience with using a template-based API. I vowed
to avoid
it wherever possible.
The culprit was std::string -- it changed something internally from
one version
of libc++ to the next
On 11/3/14 8:16 PM, Walter Bright wrote:
On 11/3/2014 2:33 PM, Steven Schveighoffer wrote:
On 11/3/14 4:40 PM, Walter Bright wrote:
On 11/3/2014 8:09 AM, Steven Schveighoffer wrote:
It is a huge difference to say EVERYONE who implements toString will
take any
templated type that purports to be
On 11/3/14 6:05 PM, Jonathan Marler wrote:
On Monday, 3 November 2014 at 22:33:25 UTC, Steven Schveighoffer wrote:
On 11/3/14 4:40 PM, Walter Bright wrote:
On 11/3/2014 8:09 AM, Steven Schveighoffer wrote:
It is a huge difference to say EVERYONE who implements toString will
take any
templated
On 11/4/14 11:01 AM, Jonathan Marler wrote:
In the past I don't get much response when I file a bug in BugZilla so I
wanted to see if anyone could tell me anything about this issue in the
forums.
I believe a bug has already been created here:
https://issues.dlang.org/show_bug.cgi?id=2372
Here's
On 11/4/14 1:05 PM, Daniel Murphy wrote:
"Steven Schveighoffer" wrote in message
news:m3b0dd$6e0$1...@digitalmars.com...
People have argued in the past that anything with a simple alias
should be doable. I don't know if that's true or not, but I don't
think it works today. There may be a bug r
On 11/4/14 4:48 PM, Walter Bright wrote:
On 11/4/2014 9:51 AM, Jonathan Marler wrote:
given the
output of Transform, the compiler cannot deduce what the input of
Transform was
EVEN IF THE TEMPLATE IS AS SIMPLE AS THIS ONE.
To answer a question not asked, why doesn't the compiler see the simple
On 11/7/14 1:05 AM, H. S. Teoh via Digitalmars-d wrote:
A little more investigation revealed the culprit: a queue object
implemented with subarrays, and subarrays were being used as stacks by
appending with ~= and popping by decrementing .length. A dangerous
combination that causes excessive rea
On 11/7/14 8:43 AM, Steven Schveighoffer wrote:
On 11/7/14 1:05 AM, H. S. Teoh via Digitalmars-d wrote:
A little more investigation revealed the culprit: a queue object
implemented with subarrays, and subarrays were being used as stacks by
appending with ~= and popping by decrementing .length.
1 - 100 of 2363 matches
Mail list logo
