On Wednesday, 12 July 2017 at 13:22:46 UTC, Meta wrote:
D is not ML or Haskell or Idris. Rust has trod this ground
before us and they saw it prudent to not make ! a first-class
type.
Only to turn around after they realized their mistake:
https://doc.rust-lang.org/stable/book/second-edition/ch
On Sunday, 16 July 2017 at 20:44:13 UTC, Andrei Alexandrescu
wrote:
Perhaps we go the inverse route and define the bottom type as
typeof(*null). Would that simplify matters? There is some good
consistency about it:
null: a pointer to anything. But can't be dereferenced.
*null: well, therefore.
On Friday, 30 December 2016 at 13:45:23 UTC, Martin wrote:
Are there any C-like bitfields in D?
Yes - How can I use them?
No - What could be used in their stead?
Not built-in, but in the standard library:
https://dlang.org/phobos/std_bitmanip.html#.bitfields
On Tuesday, 27 December 2016 at 17:27:14 UTC, unDEFER wrote:
Hello I have very simple line with exec-command:
execl("/bin/bash".toStringz(), "/bin/bash".toStringz(),
"-c".toStringz(), command.toStringz(), null);
And on this line on toStringz my program sometimes hangs.
backtrace:
(gdb) bt
#0
On Monday, 7 November 2016 at 16:48:55 UTC, John Colvin wrote:
Some people use ref for performance to prevent the copying that
must occur when passing by value. I propose a small
optimisation to make this unnecessary in a bunch of cases.
At the ABI level (no change in language semantics), if a
On Saturday, 5 November 2016 at 01:21:48 UTC, Stefan Koch wrote:
I thought about it some more, and decided that I will replace
the old interpreter completely in the long run.
However in order to get something release before 2017, I have
to rely on it being there.
That's better of course. Paral
On Friday, 4 November 2016 at 01:19:36 UTC, Chris Wright wrote:
On Thu, 03 Nov 2016 15:44:20 +, Marc Schütz wrote:
On Tuesday, 1 November 2016 at 17:41:35 UTC, Stefan Koch wrote:
I intend to keep the current implemntation around as a
fallback.
For things that are used rarely.
like floatin
On Thursday, 3 November 2016 at 16:35:08 UTC, Stefan Koch wrote:
On Thursday, 3 November 2016 at 15:44:20 UTC, Marc Schütz wrote:
On Tuesday, 1 November 2016 at 17:41:35 UTC, Stefan Koch wrote:
I intend to keep the current implemntation around as a
fallback.
For things that are used rarely.
li
On Tuesday, 1 November 2016 at 17:41:35 UTC, Stefan Koch wrote:
I intend to keep the current implemntation around as a fallback.
For things that are used rarely.
like floating point and others :)
Is that a good idea? It means that there will be tons of really
complex code that is rarely if eve
On Friday, 21 October 2016 at 13:42:49 UTC, Adam D. Ruppe wrote:
On Friday, 21 October 2016 at 13:33:26 UTC, Stefan Koch wrote:
It does create a lambda?
Hmm that should not happen.
Eh, that's exactly what the language rules say should happen,
and it actually does make sense to me... you might
On Thursday, 29 September 2016 at 17:47:41 UTC, Walter Bright
wrote:
On 9/29/2016 4:45 AM, Marc Schütz wrote:
And `Foo` could have `@disabled this()`, so you simply _can't_
declare it
without initializing it
Foo foo = void;
That's even worse. At least Foo.init would be deterministic.
Please have a look at this PR:
https://github.com/dlang/dmd/pull/6140
However, the error message printed with this PR isn't
particularly helpful either:
Error: incompatible types for ((5) in (m2)): 'int' and
'const(MyTable)'
You might want to add a comment there, and/or open an enhancement
r
On Wednesday, 28 September 2016 at 22:12:27 UTC, Idan Arye wrote:
Foo foo;
try {
foo = Foo();
} catch (FooCreationException) {
// ...
} else {
foo.doSomethingWithFoo();
}
// foo exists here - it could be initialized, it could be
not...
And `Foo`
On Thursday, 29 September 2016 at 09:22:56 UTC, Martin Nowak
wrote:
On Monday, 26 September 2016 at 22:34:59 UTC, Andrei
Alexandrescu wrote:
That would work out as long as interaction is seamless. Please
advise. Overall: I think Ilya's work can make a real
difference for D, and we can't afford
On Tuesday, 6 September 2016 at 17:01:28 UTC, Timon Gehr wrote:
There can be no field (or variables) of type 'void'.
(void,void,T) has two fields of type 'void'.
Just fixing the limitations is also not really possible, as
e.g. void* and void[] exploit that 'void' is special and have a
non-com
On Wednesday, 7 September 2016 at 10:31:13 UTC, finalpatch wrote:
I think the problem here is two fold.
First question, how do we combine pipeline stages with minimal
overhead
I think the key to this problem is reliable *forceinline*
for example, a pipeline like this
input.map!(x=>x.f1().f2
On Saturday, 3 September 2016 at 11:24:01 UTC, Walter Bright
wrote:
On 9/3/2016 3:12 AM, Walter Bright wrote:
If you are still determined to use it, you can use:
__traits(compiles, ...)
like you would SFINAE in C++ to select which of the modules
from the argument
types selects a function
On Tuesday, 30 August 2016 at 15:45:26 UTC, Andrei Alexandrescu
wrote:
On 08/30/2016 10:44 AM, Atila Neves wrote:
I'd much rather have `assert` be magical or have AST macros to
make the
syntax for writing tests better than what it is now.
Same here. BTW I'd like unittests that "must not compi
On Saturday, 13 August 2016 at 12:47:40 UTC, Ethan Watson wrote:
| Rust | Swift |C# |
-|-+-+-|
Template Constraints |Y|Y| where | [1]
-|-+
My comments:
1) `scope` on local variables is unnecessary. Requiring it
probably makes the implementation easier, but it doesn't need to
be specified explicitly because it can always be inferred. It's a
tradeoff: do we want to make it easier for compiler writers to
implement, or do we want to
On Thursday, 2 June 2016 at 23:29:57 UTC, Timon Gehr wrote:
void foo(scope int* k){
void bar(){
scope int* x;
// need to check that lifetime of x ends not after
lifetime of k
assign(x,k);
}
}
I.e. now we need a way to annotate 'assign' in order to specify
the
On Thursday, 2 June 2016 at 14:28:44 UTC, Andrei Alexandrescu
wrote:
That's not going to work. A false impression created in this
thread has been that code points are useless
They _are_ useless for almost anything you can do with strings.
The only places where they should be used are std.uni a
On Thursday, 2 June 2016 at 13:11:10 UTC, Steven Schveighoffer
wrote:
On 6/1/16 6:31 AM, Marc Schütz wrote:
I believe everything that does only concatenation will work
correctly.
That's why joiner() is one of those algorithms that should
accept
strings directly without going through any decodin
On Wednesday, 1 June 2016 at 14:29:58 UTC, Andrei Alexandrescu
wrote:
On 06/01/2016 06:25 AM, Marc Schütz wrote:
On Tuesday, 31 May 2016 at 21:01:17 UTC, Andrei Alexandrescu
wrote:
The point is to operate on representation-independent entities
(Unicode code points) instead of low-level
represe
On Wednesday, 1 June 2016 at 01:13:17 UTC, Steven Schveighoffer
wrote:
On 5/31/16 4:38 PM, Timon Gehr wrote:
What about e.g. joiner?
Compiler error. Better than what it does now.
I believe everything that does only concatenation will work
correctly. That's why joiner() is one of those algor
On Tuesday, 31 May 2016 at 21:01:17 UTC, Andrei Alexandrescu
wrote:
On 05/31/2016 04:01 PM, Jonathan M Davis via Digitalmars-d
wrote:
Wasn't the whole point of operating at the code point level by
default to
make it so that code would be operating on full characters by
default
instead of choppi
On Tuesday, 31 May 2016 at 20:56:43 UTC, Andrei Alexandrescu
wrote:
On 05/31/2016 03:44 PM, Jonathan M Davis via Digitalmars-d
wrote:
In the vast majority of cases what folks care about is full
character
How are you so sure? -- Andrei
He doesn't need to be sure. You are the one advocating fo
On Tuesday, 31 May 2016 at 16:29:33 UTC, Joakim wrote:
UTF-8 is an antiquated hack that needs to be eradicated. It
forces all other languages than English to be twice as long,
for no good reason, have fun with that when you're downloading
text on a 2G connection in the developing world.
I as
On Monday, 30 May 2016 at 21:51:36 UTC, Walter Bright wrote:
On 5/30/2016 8:34 AM, Marc Schütz wrote:
In an ideal world, we'd also want to change the way `length`
and `opIndex` work,
Why? strings are arrays of code units.
So, strings are _implemented_ as arrays of code units. But
indiscrimi
On Monday, 30 May 2016 at 14:56:36 UTC, ag0aep6g wrote:
All this is only sensible when we move to a dedicated string
type that's not just an alias of `immutable(char)[]`.
`immutable(char)[]` explicitly is an array of code units. It
would not be acceptable, in my opinion, if the normal array
s
On Saturday, 28 May 2016 at 12:04:20 UTC, Andrei Alexandrescu
wrote:
On 5/28/16 6:59 AM, Marc Schütz wrote:
The fundamental problem is choosing one of those possibilities
over the
others without knowing what the user actually wants, which is
what both
BEFORE and AFTER do.
OK, that's a fair a
On Sunday, 29 May 2016 at 14:27:51 UTC, Nick Treleaven wrote:
What about if the RCArray (of ref count 1) is assigned to a
different one after the local ref is initialised? That is what
we're discussing -it's your example above(!)
Exactly, and then one of the two suggested approaches will have
On Saturday, 28 May 2016 at 04:28:16 UTC, Manu wrote:
On 27 May 2016 at 23:32, Andrei Alexandrescu via Digitalmars-d
wrote:
On 5/27/16 7:07 AM, Marc Schütz wrote:
It should _safely_ convert to `const(char)[]`.
That is not possible, sorry. -- Andrei
It should safely convert to 'scope const
On Friday, 27 May 2016 at 13:32:30 UTC, Andrei Alexandrescu wrote:
On 5/27/16 7:07 AM, Marc Schütz wrote:
On Thursday, 26 May 2016 at 16:11:22 UTC, Andrei Alexandrescu
wrote:
RFC: what primitives should RCStr have?
It should _safely_ convert to `const(char)[]`.
That is not possible, sorry.
On Friday, 27 May 2016 at 13:34:33 UTC, Andrei Alexandrescu wrote:
On 5/27/16 6:56 AM, Marc Schütz wrote:
It is not, which has been shown by various posts in this
thread.
Couldn't quite find strong arguments. Could you please be more
explicit on which you found most convincing? -- Andrei
Th
On Friday, 27 May 2016 at 10:04:14 UTC, Nick Treleaven wrote:
On Thursday, 26 May 2016 at 08:29:41 UTC, Marc Schütz wrote:
To elaborate: neither `scope` nor reference counting can ever
protect you against explicit premature destruction of a
still-referenced owner. But there is a slightly differ
On Thursday, 26 May 2016 at 16:11:22 UTC, Andrei Alexandrescu
wrote:
RFC: what primitives should RCStr have?
It should _safely_ convert to `const(char)[]`.
On Thursday, 26 May 2016 at 16:00:54 UTC, Andrei Alexandrescu
wrote:
This might be a good time to discuss this a tad further. I'd
appreciate if the debate stayed on point going forward. Thanks!
My thesis: the D1 design decision to represent strings as
char[] was disastrous and probably one of
On Tuesday, 24 May 2016 at 02:01:14 UTC, cy wrote:
void transaction(Callable)(Callable do_stuff)
`scope` to avoid GC
if(isCallable(Callable)) {
begin();
scope(failure) rollback();
scope(success) commit();
do_stuff();
}
On Wednesday, 25 May 2016 at 19:47:06 UTC, Nick Treleaven wrote:
On 24/05/2016 14:48, Nick Treleaven wrote:
What about:
@safe unittest
{
RCArray!int arr;
+ arr.length = 1;
ref r = arr[0];
arr.destroy; // refcount drops to zero, arr.impl memory
freed
r++; // writes t
On Tuesday, 24 May 2016 at 13:48:41 UTC, Nick Treleaven wrote:
What about:
@safe unittest
{
RCArray!int arr;
ref r = arr[0];
arr.destroy; // refcount drops to zero, arr.impl memory freed
r++; // writes to unallocated memory
}
You're calling `destroy` explicitly,
On Monday, 23 May 2016 at 15:18:51 UTC, Nick Treleaven wrote:
On Monday, 23 May 2016 at 14:05:43 UTC, deed wrote:
Some thoughts about extending the with-statement were brought
up here earlier:
http://forum.dlang.org/post/txpifmwpmmhsvcpbc...@forum.dlang.org
I don't care much whether it would be
On Friday, 20 May 2016 at 13:24:42 UTC, Andrei Alexandrescu wrote:
I don't see a need for hashing something. Would a
randomly-generated string suffice?
That would break separate compilation, wouldn't it?
On Saturday, 14 May 2016 at 04:34:06 UTC, Andrei Alexandrescu
wrote:
On 5/13/16 2:27 PM, Russel Winder via Digitalmars-d wrote:
getopt is a 1970s C solution to the problem of command line
parsing.
Most programming languages have moved on from getopt and
created
language-idiomatic solutions to t
On Friday, 13 May 2016 at 10:38:09 UTC, Jonathan M Davis wrote:
Ideally, algorithms would be Unicode aware as appropriate, but
the default would be to operate on code units with wrappers to
handle decoding by code point or grapheme. Then it's easy to
write fast code while still allowing for ful
On Thursday, 12 May 2016 at 23:16:23 UTC, H. S. Teoh wrote:
Therefore, autodecoding actually only produces intuitively
correct results when your string has a 1-to-1 correspondence
between grapheme and code point. In general, this is only true
for a small subset of languages, mainly a few common
On Thursday, 12 May 2016 at 20:15:45 UTC, Walter Bright wrote:
7. Autodecode cannot be used with unicode path/filenames,
because it is legal (at least on Linux) to have invalid UTF-8
as filenames. It turns out in the wild that pure Unicode is not
universal - there's lots of dirty Unicode that s
On Monday, 9 May 2016 at 08:44:53 UTC, Dmitry Olshansky wrote:
On 09-May-2016 02:38, Jon D wrote:
[...]
The only problem is that it should consider multi-codepoint
replacements aka full-case folding in Unicode.
Otherwise - go ahead and issue a pull request to add
special case for < 0x80.
W
On Tuesday, 26 April 2016 at 12:53:49 UTC, deed wrote:
Would it be possible to extend current with statement's
expressiveness by two lowerings:
1) Alias expression/symbol and replace in macro fashion:
with (a : exprA) { /* use a. will be replaced by exprA by
compiler. */ }
2) Accept a list
On Monday, 25 April 2016 at 17:52:58 UTC, Andrei Alexandrescu
wrote:
Idea #1: Detect and use CNF, print which clause failed
I prefer this one, because it should work without modifying
library or user code.
Idea #2: Allow custom error messages
The basic idea here is to define pra
On Thursday, 21 April 2016 at 12:45:34 UTC, Steven Schveighoffer
wrote:
On 4/19/16 6:04 PM, Stefan Koch wrote:
On Tuesday, 19 April 2016 at 14:53:18 UTC, Steven
Schveighoffer wrote:
or we
should do away with requiring handling all enum cases.
Are you suggesting getting rid of final switch
On Tuesday, 19 April 2016 at 06:31:13 UTC, Sönke Ludwig wrote:
This is a rather important pull request and the last big
milestone for the 1.0.0 release. I'd like to get the next
version out shortly, but this PR is sitting idle for over a
month now and partially blocks development.
It consists
On Saturday, 16 April 2016 at 11:49:21 UTC, Nick Treleaven wrote:
On 16/04/2016 12:40, Marc Schütz wrote:
What are the plans for DIP25's `return` attribute? Because
with it, the
compiler has enough information to know that the return value
aliases `s`:
const(T)[] replaceSlice(T)(const(T)[] s
On Sunday, 17 April 2016 at 02:03:06 UTC, Adam D. Ruppe wrote:
BTW, my superior doc site handles it this way:
http://dpldocs.info/experimental-docs/std.experimental.allocator.html
It marries the package.d contents along with the other concept
of package as a collection of submodules.
The "sou
On Sunday, 17 April 2016 at 09:22:21 UTC, WebFreak001 wrote:
you need to use toImpl if you want to convert a number to/from
a specific base! I use that a lot when converting hexadecimal
values
No, the documentation just gives that impression. This works:
void main(string[] args) {
(It seems my reply got lost somewhere, reposting...)
On Friday, 15 April 2016 at 19:28:02 UTC, Andrei Alexandrescu
wrote:
A better support for this argument is std.array.replaceSlice at
https://github.com/D-Programming-Language/phobos/blob/master/std/array.d#L2594:
inout(T)[] replaceSlice(T)(
On Thursday, 14 April 2016 at 00:31:34 UTC, Simen Kjaeraas wrote:
@constanttime functions can only call other functions marked
@constanttime, and may not contain conditionals, gotos or
while-loops.
@constanttime functions may contain for and foreach-loops, iff
the number of iterations are known
On Wednesday, 23 March 2016 at 11:36:39 UTC, Nick Treleaven wrote:
On Tuesday, 22 March 2016 at 20:09:51 UTC, Matthias Bentrup
wrote:
It is logically just a combination of map and concat (which
turns a range of ranges into a combined range, but I think
that one is missing in the std lib too).
On Thursday, 17 March 2016 at 20:54:57 UTC, Johannes Pfau wrote:
It's been some time since I looked at that code, but IIRC TLS
ctors for newly loaded libraries are not run in old threads.
There's nothing we can do about this without help from the C
runtime.
Hmm... are all module _destructors_
On Tuesday, 15 March 2016 at 09:13:10 UTC, Nordlöw wrote:
On Monday, 14 March 2016 at 09:04:28 UTC, Nordlöw wrote:
http://klickverbot.at/code/units/std_units.html
http://klickverbot.at/code/units/std_units.html#PrefixSystem
No module name in Phobos is currently in plural form.
std.traits
st
On Friday, 11 March 2016 at 13:26:49 UTC, Meta wrote:
On Thursday, 10 March 2016 at 19:36:05 UTC, ZombineDev wrote:
On Monday, 7 March 2016 at 18:21:24 UTC, Meta wrote:
Unfortunately this will not work. There was a tuple proposal
sometime back in 2012 or 2013. I can't remember the exact
reason
On Tuesday, 8 March 2016 at 20:32:02 UTC, Idan Arye wrote:
Declaring the named arguments variadically will be done by
adding `...` after a struct argument:
struct Options{int x; int y=1; int z=2;}
auto fun(Options options ...)
We'll need a syntax for specifying the arguments - but that
On Tuesday, 8 March 2016 at 18:01:25 UTC, Lodovico Giaretta wrote:
- one accepting InputRanges, that can work with almost any data
source and does not require the entire input to be available at
the same time; it's cons are that it must allocate lots of
small strings (one for each token) and gr
On Monday, 7 March 2016 at 18:21:24 UTC, Meta wrote:
On Monday, 7 March 2016 at 10:40:15 UTC, ZombineDev wrote:
Which I don't think will cause ambiguity with delegates:
auto tuple3 = { getInt() }; tuple
auto tuple3 = { getInt(); }; lambda
Unfortunately this will not work. There was a tuple pro
On Friday, 26 February 2016 at 23:11:32 UTC, Andrei Alexandrescu
wrote:
On 02/26/2016 06:09 PM, Andrei Alexandrescu wrote:
static if (is(partition == function) || is(partition ==
delegate))
partition(r);
else if (__traits(compiles, partition!less(r, n)))
partition!less(r, n);
else
part
Digger shows that it stopped working after this PR:
https://github.com/D-Programming-Language/dmd/pull/4457
I could reduce it as far as this:
struct RefCounted(T) {
struct Impl {
T _payload;
}
Impl* _store;
~this() {
destroy(_store._payload);
}
}
struct Con
On Thursday, 25 February 2016 at 17:33:34 UTC, Jonathan M Davis
wrote:
Actually, both of your examples compile for me - both with
master and with 2.070.0. I'm running on x86_64 FreeBSD (which
you probably aren't), which shouldn't matter for this sort of
error, but I suppose that it's possible t
On Sunday, 21 February 2016 at 18:19:35 UTC, Nick Treleaven wrote:
BTW the Usage section still uses lazy. I think the RCObject
code shouldn't use new to construct the struct here:
auto o = new immutable(RCObject);
It probably needs to be on the stack instead.
Thanks, fixed.
(I also made a
I've adapted my previous DIP on lazy initialization to make it
usable for logical immutability, as is useful for reference
counting, among other things:
http://wiki.dlang.org/DIP89
On Friday, 19 February 2016 at 21:53:16 UTC, Walter Bright wrote:
On 2/19/2016 4:38 AM, Jonathan M Davis wrote:
Why not? I would expect the opaque type to have to have it
too, e.g.
@mutable struct S;
That would mean you're proposing '@mutable const' as a type
constructor, which you'd e
On Friday, 19 February 2016 at 06:39:53 UTC, Walter Bright wrote:
Allow @mutable, and no more mechanical checking in D. Recall
that D supports opaque types, meaning types are not fully known
to the compiler.
Allow @trusted, an no more mechanical checking in D. Recall that
D supports extern fu
On Friday, 19 February 2016 at 00:45:00 UTC, Walter Bright wrote:
On 2/18/2016 6:04 AM, Marc Schütz wrote:
Rule 2 only forbids _static immutables_ with @mutable members,
precisely because
those could end up in read-only memory. I don't see how
allocators are affected
at all. An allocator would
On Thursday, 18 February 2016 at 11:12:40 UTC, Dicebot wrote:
On 02/17/2016 08:48 PM, Marc Schütz wrote:
On Wednesday, 17 February 2016 at 02:20:15 UTC, Dicebot wrote:
One example of a existing guarantee you won't be able to
keep, for example, is that any immutable allocation can be
completely
On Wednesday, 17 February 2016 at 02:51:06 UTC, Walter Bright
wrote:
On 2/16/2016 11:29 AM, Marc Schütz wrote:
For example, it's always possible to use a global mutable
associative array to
store additional data connected with an immutable or const
object (ignoring
purity issues for the moment)
On Wednesday, 17 February 2016 at 02:20:15 UTC, Dicebot wrote:
One example of a existing guarantee you won't be able to keep,
for example, is that any immutable allocation can be completely
put into separate read-only memory.
Yes, and it would be rejected statically (rule 2). I therefor
don't
On Wednesday, 17 February 2016 at 01:09:20 UTC, Adam D. Ruppe
wrote:
On Wednesday, 17 February 2016 at 00:45:35 UTC, Chris Wright
wrote:
http://dpldocs.info/search/search?searchTerm=emplace to create
an exception object in manually allocated memory.
Aye, this overload:
http://dpldocs.info/exp
On Tuesday, 16 February 2016 at 13:35:56 UTC, Dicebot wrote:
On 02/16/2016 02:49 PM, Marc Schütz wrote:
`@mutable` OTOH would be a useful for both C++, reference
counting, caching, lazy initialization... But we need to find
a way to keep most of the existing guarantees, especially
concerning s
On Tuesday, 16 February 2016 at 11:27:56 UTC, Dicebot wrote:
On 02/16/2016 12:48 AM, Walter Bright wrote:
rears its head again :-)
Head Const is what C++ has for const, i.e. it is not
transitive, applies to one level only. D has transitive const.
What head const will do for us:
1. make it e
On Monday, 8 February 2016 at 13:37:19 UTC, Andrei Alexandrescu
wrote:
On 2/7/16 7:11 PM, John Colvin wrote:
alias dump = dumpTo!stdout;
alias errDump = dumpTo!stderr;
I'm hoping for something with a simpler syntax, a la
dump!(stdout, "x") where stdout is optional. -- Andrei
Why would `stdo
On Wednesday, 3 February 2016 at 19:25:20 UTC, Jonathan M Davis
wrote:
Now, in this particular case, you're talking about features
that were warned about starting in 2.067, which was released at
the end of March of last year. Removing them now would be
awfully quick. The deprecation cycle in Ph
Can someone point me to our current deprecation policy?
The "Deprecated Features" page [1] lists some features that we
already warn about for some time, that could probably be moved
forward. `.sort/.reverse` in particular is something we should
get rid of better sooner than later.
[1] http:/
It seems this is a natural consequence of the lowering. As such,
I'm not surprised by the behaviour, of course under the
assumption I - as an end user - actually know that the given
opApply catches the exception. I guess there could be a
recommendation in opApply's specification that implemento
On Monday, 1 February 2016 at 07:13:32 UTC, xenon325 wrote:
On Sunday, 31 January 2016 at 16:18:21 UTC, bearophile wrote:
And currently it's dead-easy to write unsafe code even in
@safe D functions:
int[] foo() pure @safe {
int[2] a = [10, 20];
auto b = a[];
return b;
}
void main()
On Wednesday, 27 January 2016 at 17:08:09 UTC, Andrei
Alexandrescu wrote:
Interesting. It may be worked around, but is arguably a mistake
in the language definition. Have you submitted an issue for
this? -- Andrei
1) https://issues.dlang.org/show_bug.cgi?id=14246
Includes suggestion on how th
On Saturday, 23 January 2016 at 16:38:13 UTC, Jacob Carlborg
wrote:
void foo(int a:, string b:);
void foo(string b:, int a:);
void main()
{
foo(a: 3, b: "asd");
}
What should happen in the above example? Error or which
function should be called?
I hadn't take this into consideration; ind
On Saturday, 23 January 2016 at 14:19:03 UTC, Jacob Carlborg
wrote:
This is mostly to prevent ugly hacks like Flag [1].
http://wiki.dlang.org/DIP88
[1] https://dlang.org/phobos/std_typecons.html#.Flag
Some comments:
1) Default values
You should specify how to use both the `:` syntax and a d
On Thursday, 21 January 2016 at 20:42:17 UTC, Jack Stouffer wrote:
On Thursday, 21 January 2016 at 19:31:19 UTC, Andrei
Alexandrescu wrote:
* Do NOT alias Flag!"frob" to a new name. This is unnecessary,
unhelpful, and wasteful.
I disagree. Making an alias means the user does not have to
impor
On Thursday, 21 January 2016 at 00:51:34 UTC, Anon wrote:
What would you all say to the following proposal (and should I
make a DIP?)
1. deprecate pragma(mangle)
2. deprecate extern(C++, ns)
3. deprecate @selector()
4. Introduce a better, more general extern() as follows:
extern ( [, ] )
..
For the website, definitely number 3. As a standalone version,
the fourth one can be used. Or if we insist on the "horizon" arc,
maybe a version can be made that fades out the arc much closer to
the "D", so that the entire logo fits into a nearly-square
rectangle.
On Wednesday, 20 January 2016 at 17:25:56 UTC, JohnCK wrote:
On Wednesday, 20 January 2016 at 16:38:19 UTC, Marc Schütz
wrote:
I think the first error is correct:
bar(); // Error: b.bar at b.d(6) conflicts with
a.ns.bar at a.d(5)
Yes, I put this one in to show why the next lines a
On Wednesday, 20 January 2016 at 05:32:08 UTC, Walter Bright
wrote:
Actual code examples of the serious problems would be
appreciated. All the namespace code examples you posted were
bugs that have since been fixed, or were misunderstandings that
were explained.
IMO his description was alread
On Friday, 15 January 2016 at 12:36:32 UTC, Andrei Alexandrescu
wrote:
On 1/15/16 6:58 AM, Craig Dillabaugh wrote:
On Friday, 15 January 2016 at 10:02:14 UTC, Marc Schütz wrote:
* A flexible serialization framework in Phobos. std.csv could
be
changed to use it, and vibe.d as well as various
se
On Friday, 15 January 2016 at 03:33:23 UTC, Andrei Alexandrescu
wrote:
A few quick ideas:
* Bringing a parser generator library into phobos, either based
on pegged or independent
* SQL parser, binder, validator
* Anything building on the strengths on D: introspection,
compile-time stuff, DS
On Wednesday, 13 January 2016 at 06:01:41 UTC, Vladimir Panteleev
wrote:
http://beta.forum.dlang.org/
https://github.com/CyberShadow/DFeed/pull/51
It's much too white for my taste; the old version is more easy on
the eyes. And there's a white margin left of the menu bar.
On Wednesday, 6 January 2016 at 17:55:01 UTC, Walter Bright wrote:
Found and fixed another fwd ref problem with circular imports:
https://github.com/D-Programming-Language/dmd/pull/5333
This one had nothing to do with C++ namespaces; it showed up
for structs and classes, too. This implies th
On Tuesday, 5 January 2016 at 22:12:05 UTC, Mengu wrote:
but as a web developer, i don't mind if i have to type
User.where("first_name = ? AND age > 27",
request.POST.get('name')). this will generate the same query
above. i added the question mark to say the parameters should
be escaped proper
On Sunday, 3 January 2016 at 17:53:38 UTC, Walter Bright wrote:
On 1/3/2016 9:14 AM, Marc Schütz wrote:
On Sunday, 3 January 2016 at 16:18:13 UTC, Walter Bright wrote:
No. If D is to support C++ namespaces, it has to support
declaring the same
identifier for different purposes in different name
On Sunday, 3 January 2016 at 16:18:13 UTC, Walter Bright wrote:
No. If D is to support C++ namespaces, it has to support
declaring the same identifier for different purposes in
different namespaces. C++ namespaces have different scopes in
C++. Doing anything else would make it impossible to con
On Monday, 21 December 2015 at 09:06:08 UTC, Shriramana Sharma
wrote:
http://dlang.org/spec/template.html#TemplateTupleParameter
Apart from the obvious need for changing the references to
tuples to alias sequences (for which I'm working on a PR), my
question:
Both the above page and http://d
On Wednesday, 16 December 2015 at 22:32:25 UTC, H. S. Teoh wrote:
On Wed, Dec 16, 2015 at 10:00:50PM +, Meta via
Digitalmars-d wrote:
There's also weird stuff like this, with an outer template and
a documented inner template function.
http://dlang.org/phobos/std_parallelism.html#.TaskPool.
1 - 100 of 151 matches
Mail list logo
