On 01/20/2016 06:16 PM, Andrei Alexandrescu wrote:
This is one of those cases in which we were pedantically right to not
add them, but their equivalents look like crap.
https://github.com/D-Programming-Language/phobos/pull/3942
Andrei
One reason why dual notions usually both receive names
On 01/22/2016 01:57 PM, maik klein wrote:
It seems that D doesn't have a way to express C++'s fold
expression/template expansions.
For example in C++ I could write
std::make_tuple(std::ref(ts)...);
and it would expand like
std::make_tuple(std::ref(t1), std::ref(t2), ... , std::ref(tn));
On 16.02.2016 01:14, H. S. Teoh via Digitalmars-d wrote:
Just out of curiosity, since we already have Rebindable in Phobos and
HeadConst is being proposed, what are the disadvantages / shortcomings
of a library solution that would justify adding yet another feature to
the language?
struct S{
On 16.02.2016 11:21, krzaq wrote:
By the way, your example in C++ would be even worse:
auto sum_of_filtered = x
.map([&](auto&& val){ foo(val); })
.filter([](auto&& val){ return is_bar(val); })
.reduce(std::plus<>{});
vs
auto sum_of_filtered =
reduce(filter(map(x, [&](auto&&
On 16.02.2016 11:17, Jonathan M Davis wrote:
On Tuesday, 16 February 2016 at 10:06:12 UTC, ZombineDev wrote:
Another bonus to introducing the mutable keyword is the option to make
everything immutable by default (in a future version of D) and allow
the users to have mutable objects only if they
On 16.02.2016 14:41, Ola Fosheim Grøstad wrote:
On Tuesday, 16 February 2016 at 13:35:56 UTC, Dicebot wrote:
matter how it is designed. Once you start considering it, you are
better at simply throwing away existing const system and starting it
all from scratch with D3. Logical const is harmful
On 18.02.2016 08:51, Walter Bright wrote:
On 2/17/2016 4:41 PM, Jonathan M Davis wrote:
Yes, but that really isn't going to help much code. It would be
useless for
ref-counting const objects, it wouldn't allow you to put a mutex in a
const
object, and you couldn't do anything with caching
On 18.02.2016 10:24, Walter Bright wrote:
On 2/17/2016 11:58 PM, Timon Gehr wrote:
const(headconst(T)) is the same as const(T), no?
Er, yes?
Jonathan wanted to embed a mutable reference count within a const
object. Contrary to your suggestion, headconst won't help with that.
On 18.02.2016 13:03, Walter Bright wrote:
On 2/18/2016 2:47 AM, Timon Gehr wrote:
On 18.02.2016 10:24, Walter Bright wrote:
On 2/17/2016 11:58 PM, Timon Gehr wrote:
const(headconst(T)) is the same as const(T), no?
Er, yes?
Jonathan wanted to embed a mutable reference count within a const
On 18.02.2016 17:37, H. S. Teoh via Digitalmars-d wrote:
While @safe is a good idea in principle, the current implementation is
rather lackluster. Consider, for example:
void readData(void[] buffer) @safe
{
ubyte[] buf = cast(ubyte[]) buffer;
On 18.02.2016 19:41, Steven Schveighoffer wrote:
On 2/18/16 1:30 PM, Timon Gehr wrote:
On 18.02.2016 17:37, H. S. Teoh via Digitalmars-d wrote:
While @safe is a good idea in principle, the current implementation is
rather lackluster. Consider, for example:
void readData(void[] buffer)
On 18.02.2016 19:41, H. S. Teoh via Digitalmars-d wrote:
On Thu, Feb 18, 2016 at 07:30:34PM +0100, Timon Gehr via Digitalmars-d wrote:
On 18.02.2016 17:37, H. S. Teoh via Digitalmars-d wrote:
[...]
1) Casting an array of elements with indirections (in this case
Object[]) to void
On 18.02.2016 20:17, Era Scarecrow wrote:
On Thursday, 18 February 2016 at 18:41:25 UTC, Steven Schveighoffer wrote:
On 2/18/16 1:30 PM, Timon Gehr wrote:
No problem here. There is no way to assign to a void[] without doing 2.
foo(void[] arr)
{
void[] arr2 = [1234, 5678, 91011];
arr[]
On 18.02.2016 21:57, H. S. Teoh via Digitalmars-d wrote:
>If you want to verify guarantees, @safe should be specified by
>inclusion and ideally, type safety should be proved formally (after
>applying a few fixes).
>This first requires a formal language semantics.
>That's already a lot of effort,
On 20.02.2016 15:01, Andrei Alexandrescu wrote:
Do we have a good quality converter of uniform numbers to
Gaussian-distributed numbers around? -- Andrei
I don't know about quality, but the following is in Phobos:
https://dlang.org/phobos/std_mathspecial.html#.normalDistributionInverse
On 12.02.2016 20:12, Andrei Alexandrescu wrote:
https://github.com/D-Programming-Language/phobos/pull/3991
A short while ago Dicebot discussed the notion of using the allocator to
store the reference count of objects (and generally metadata). The
allocator seems to be a good place because in a
On 13.02.2016 01:30, Andrei Alexandrescu wrote:
On 02/12/2016 06:29 PM, Timon Gehr wrote:
The first thing that comes to mind is that accessing a global
associative array is not 'pure'.
The weird thing is in this case is. The analogy is limited. -- Andrei
Why is it limited? Accessing the
On 12.02.2016 20:12, Andrei Alexandrescu wrote:
* If the buffer is mutable, then the allocator assumes it hasn't been
shared across threads, so it returns a reference to a mutable affix.
* If the buffer is const, then the allocator must conservatively assume
it might have been immutable and
On 12.03.2016 08:58, deadalnix wrote:
IMO, this *should* compile and infer T == const(SomeStruct) as the
common type of a and b. But I'm not sure whether or not this is a
regression.
T
More tricky actually.
If T has indirection, then that is the correct answer. If not, the T ==
On 07.04.2016 22:17, Nordlöw wrote:
On Thursday, 7 April 2016 at 18:13:16 UTC, Mike Parker wrote:
I'm flying in to Berlin late on May 2nd. I'll be staying at the Hotel
Ibis, slated to be the "unofficial hangout place" according to the
DConf site. I'm curious who else will be in the area on the
On 06.04.2016 15:15, Andrei Alexandrescu wrote:
I just got word about Sparrow (from its creator no less):
presentation_offline_Sparrow.pdf - https://db.tt/m2WwpxIY
The sum of squares of odd fibonacci numbers example is... unconvincing.
It is inefficient and incorrect.
Speak.mp4 -
On 06.04.2016 06:16, Walter Bright wrote:
On 4/5/2016 4:08 PM, Timon Gehr wrote:
Some additional care will need to be taken, e.g.
/+
or even simply
/+ comment +/
that should not be a problem.
I think it can be for large files if the highlighter implements the
described strategy in a
On 05.04.2016 21:24, Timon Gehr wrote:
On 05.04.2016 07:39, Timothee Cour via Digitalmars-d wrote:
what's D's answer for C++11's uniform initialization [1] which allows
DRY code?
If it's just about DRY...
NVM, I see those points have been brought up already (the thread was
split into
On 05.04.2016 07:39, Timothee Cour via Digitalmars-d wrote:
what's D's answer for C++11's uniform initialization [1] which allows DRY code?
If it's just about DRY, D is in quite good shape.
A fun(A a, int b) {
alias i=typeof(return);
if(b==1) return i(0,1);
else if(b==2) return
On 05.04.2016 17:29, ZombineDev wrote:
On Tuesday, 5 April 2016 at 05:45:08 UTC, Timothee Cour wrote:
{} for tuples hasn't worked out since it was deemed ambiguous with
delegate syntax (was it for the case of empty statements/tuple?).
How about the following syntax instead:
{} //
On 10.04.2016 12:01, Lucian Radu Teodorescu wrote:
On Wednesday, 6 April 2016 at 21:42:31 UTC, Timon Gehr wrote:
The sum of squares of odd fibonacci numbers example is...
unconvincing. It is inefficient and incorrect.
How would you do it?
The Fibonacci example isn't very complex, but the idea
On 10.04.2016 13:00, Timon Gehr wrote:
On 10.04.2016 12:01, Lucian Radu Teodorescu wrote:
On Wednesday, 6 April 2016 at 21:42:31 UTC, Timon Gehr wrote:
The sum of squares of odd fibonacci numbers example is...
unconvincing. It is inefficient and incorrect.
How would you do it?
The Fibonacci
On 05.04.2016 22:48, ZombineDev wrote:
On Tuesday, 5 April 2016 at 20:13:59 UTC, Timon Gehr wrote:
On 05.04.2016 17:29, ZombineDev wrote:
On Tuesday, 5 April 2016 at 05:45:08 UTC, Timothee Cour wrote:
{} for tuples hasn't worked out since it was deemed ambiguous with
delegate syntax (was it
On 05.04.2016 10:46, Walter Bright wrote:
On 1/16/2016 7:13 AM, H. S. Teoh via Digitalmars-d wrote:
I disagree. I think having the dmd itself (lexer, parser, etc.) as a
library (with the dmd executable merely being the default frontend) will
do D a lot of good.
For one thing, IDE's will no
On 17.03.2016 23:36, maarten van damme via Digitalmars-d wrote:
> This very sexist and you are clearly either very young or a closet
misogynist
Great, so you answer a poorly thought out attempt to encourage women to
join this community by bashing on younger people?
No. That statement does
On 19.03.2016 09:38, Basile B. wrote:
identifier : type = initializer; // straight declaration
identifier : type; // no init
identifier := initializer; // infered type
However later in the function declaration:
"sum := (x: float, y: float, z: float) -> float {
return x + y + z;
};"
I
On 25.03.2016 13:31, jmh530 wrote:
On Friday, 25 March 2016 at 07:14:52 UTC, Seb wrote:
- dont add @nogc, @pure, @safe attributes yourself - let the compiler
infer it!
- avoid to use `auto` as return type
But auto functions are a key way to infer attributes.
Which is why it was argued by
On 26.03.2016 01:34, Bruno Medeiros wrote:
On 25/03/2016 04:52, Walter Bright wrote:
On 3/24/2016 4:16 PM, tsbockman wrote:
[...]
Maybe we should leave politics out of this forum. It adds no relevance
to programming, generates lots of bad feeling, and there are certainly
plenty of political
On 07.03.2016 06:08, Walter Bright wrote:
On 3/5/2016 11:38 PM, Ali Çehreli wrote:
Motivated by Dmitry's "Pitching D to a gang of Gophers" thread, how about
pitching it to a gang of professors and graduate students?
I will be presenting D to such an audience at METU in Ankara. What are
the
On 07.03.2016 18:49, Wyatt wrote:
But I really don't want any language features predicated on the
programmer having an APL keyboard.
I can't think of any language feature that would be.
On 07.03.2016 01:19, Xinok wrote:
On Sunday, 6 March 2016 at 07:45:58 UTC, Ola Fosheim Grøstad wrote:
I think it would be better idea to just add the ability to add unicode
operators, and to avoid precedence issues one could just require them
to use parentheses. That way you could define
On 01.04.2016 00:52, deadalnix wrote:
DMD optimizes malloc because the only reason it would have to return a
different pointer would be internal state (and in fact, it indeed has
internal state).
It's the other way around. Without the "optimization" there is no way
for a 'pure' function to
On 29.04.2016 07:35, tsbockman wrote:
What are the reasons that mixin shouldn't be able to be used to change
the behavior of a whole hierarchy?
Mixins are a fairly simple and elegant feature both to use, and to
implement in the compiler. Your proposal kills that simplicity,
It is not
On 26.04.2016 17:27, Xinok wrote:
On Monday, 25 April 2016 at 15:35:14 UTC, Dominikus Dittes Scherkl wrote:
On Monday, 25 April 2016 at 15:27:02 UTC, Xinok wrote:
Brute force.
http://dpaste.dzfl.pl/882d7cdc5f74
Yeah. And your test spares the failed case int.min (0x8000),
because in this
On 28.04.2016 05:55, Joakim wrote:
On Wednesday, 27 April 2016 at 18:38:17 UTC, Max Samukha wrote:
On Tuesday, 26 April 2016 at 18:16:42 UTC, Joakim wrote:
He gave very specific criticism, along with a code sample, then made
a prediction, followed by suggesting another competing language
On 28.04.2016 22:01, Seb wrote:
I agree with the other people on this list - cleaning up a language is
great and should be done.
`++` might be a bad example, but (empty) C-style for loops are!
Leave those alone.
On 26.04.2016 13:26, Marc Schütz wrote:
Currently, there is no boolean short-cut evaluation in template
constraints, see:
bool foo()() {
pragma(msg, "foo");
return true;
}
bool bar()() {
pragma(msg, "bar");
return true;
}
void
On 18.05.2016 19:10, Timon Gehr wrote:
implementation-defined behaviour
Maybe that wasn't the right term (it's worse than that; I think the
documentation of the implementation is not even required to tell you
precisely what it does).
On 19.05.2016 09:09, Walter Bright wrote:
On 5/18/2016 10:10 AM, Timon Gehr wrote:
double kahan(double[] arr){
double sum = 0.0;
double c = 0.0;
foreach(x;arr){
double y=x-c;
double y = roundToDouble(x - c);
Those two lines producing different results is
On 20.05.2016 08:12, 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 targets that will
On 20.05.2016 11:14, Joakim wrote:
On Thursday, 19 May 2016 at 18:22:48 UTC, Timon Gehr wrote:
On 19.05.2016 08:04, Joakim wrote:
On Wednesday, 18 May 2016 at 17:10:25 UTC, Timon Gehr wrote:
It's not just slightly worse, it can cut the number of useful bits in
half or more! It is not unusual,
On 22.05.2016 00:07, Walter Bright wrote:
On 5/21/2016 2:37 PM, Timon Gehr wrote:
Why is longest_match Ω(nm) instead of O(n+m) (e.g. KMP)?
I don't understand the terms you use, but as to the "why" it is based on
what I knew about LZ77 compression. I don't pretend to be an expert on
On 23.05.2016 22:34, Walter Bright wrote:
On 5/23/2016 12:32 PM, Timon Gehr wrote:
Instead, compression should be performed while generating the mangled
string.
The trouble with that is the mangled string is formed from component
pieces.
Then don't do that. I.e. re-mangle recursively from
On 21.05.2016 00:22, 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,
Authorities are not always wrong, the fallacy is to argue that they are
right *because* they are authorities. However, in
On 20.05.2016 13:32, Joakim wrote:
On Friday, 20 May 2016 at 11:02:45 UTC, Timon Gehr wrote:
On 20.05.2016 11:14, Joakim wrote:
On Thursday, 19 May 2016 at 18:22:48 UTC, Timon Gehr wrote:
On 19.05.2016 08:04, Joakim wrote:
On Wednesday, 18 May 2016 at 17:10:25 UTC, Timon Gehr wrote:
It's
On 24.05.2016 01:02, Walter Bright wrote:
On 5/23/2016 2:17 PM, Timon Gehr wrote:
Then don't do that. I.e. re-mangle recursively from scratch for each
mangled
name and allow sharing parts between unrelated components within that
mangled
name.
How is that essentially different from running a
On 20.05.2016 08:25, Walter Bright wrote:
On 5/19/2016 12:49 AM, Max Samukha wrote:
People are trying to get across that, if they wanted to maximize
accuracy, they
would request the most precise type explicitly. D has 'real' for that.
This
thread has shown unequivocally that the semantics you
On 17.05.2016 20:09, Max Samukha wrote:
On Monday, 16 May 2016 at 19:01:19 UTC, Timon Gehr wrote:
You are not even guaranteed to get the same result on two different x86
implementations.
Without reading the x86 specification, I think it is safe to claim
that you actually are guaranteed to
On 21.05.2016 23:12, Walter Bright wrote:
The current one is effective, but slow:
https://github.com/dlang/dmd/blob/master/src/backend/compress.c
Anyone want to make a stab at making it faster? Changing the format is
fair game, as well as down and dirty assembler if that's what it takes.
On 21.05.2016 19:58, Walter Bright wrote:
On 5/21/2016 2:26 AM, Tobias Müller wrote:
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
On 21.05.2016 23:37, Timon Gehr wrote:
On 21.05.2016 23:12, Walter Bright wrote:
The current one is effective, but slow:
https://github.com/dlang/dmd/blob/master/src/backend/compress.c
Anyone want to make a stab at making it faster? Changing the format is
fair game, as well as down and
On 20.05.2016 14:34, Johan Engelen wrote:
On Thursday, 19 May 2016 at 18:22:48 UTC, Timon Gehr wrote:
dmd -run kahanDemo.d
1000.00
1001.00
1000.00
dmd -m32 -O -run kahanDemo.d
1000.00
1000.00
On 21.05.2016 15:45, Timon Gehr wrote:
On 21.05.2016 00:22, Walter Bright wrote:
...
may I present
Kahan who concurrently designed the IEEE 754 spec and the x87.
The x87 is by far not the slam-dunk design you seem to make it out to
be. ...
On 21.05.2016 20:14, Walter Bright wrote:
On 5/21/2016 10:03 AM, Timon Gehr wrote:
Check out section 5 for some convincing examples showing why the x87
is horrible.
The polio vaccine winds up giving a handful of people polio, too.
...
People don't get vaccinated without consent.
It's good
On 19.05.2016 08:04, Joakim wrote:
On Wednesday, 18 May 2016 at 17:10:25 UTC, Timon Gehr wrote:
It's not just slightly worse, it can cut the number of useful bits in
half or more! It is not unusual, I have actually run into those
problems in the past, and it can break an algorithm that is in
On 11.05.2016 11:39, ZombineDev wrote:
By "parametric polymorphism" do you mean multiple dispatch/multimethods?
It's a type system feature. It allows one uniform implementation to work
on different types without a loss of type information (i.e., by using a
variant, or up-casting to a less
On 10.05.2016 23:52, Timon Gehr wrote:
Also, tuples can do everything that comma expressions can.
Actually, that doesn't work for 'void' (because 'void' is a type that is
not actually a type) in every conceivable design. Should probably just
be made to work.
On 10.05.2016 23:30, Observer wrote:
I've programmed in C for decades, and in Perl for a decade, and *never*
had a problem with the comma operator in either language.
Neither have I. It's a cheap claim to make though, and it does not
really add anything relevant to the discussion.
While I
On 10.05.2016 23:47, deadalnix wrote:
On Tuesday, 10 May 2016 at 17:57:38 UTC, Steven Schveighoffer wrote:
On 5/10/16 9:53 AM, Meta wrote:
Do you like comma expressions, and think its presence in the language
is more pro than con ?
It should've been killed off a long time ago. It only causes
On 10.05.2016 19:57, Steven Schveighoffer wrote:
On 5/10/16 9:53 AM, Meta wrote:
Do you like comma expressions, and think its presence in the language
is more pro than con ?
It should've been killed off a long time ago. It only causes bugs and
can easily be replaced with a library feature if
On 10.05.2016 11:52, Mathias Lang wrote:
It seems there is a reasonable ground to kill it. However, there have
been legitimated concern about code breakage, so we would like to hear
from other people:
Do you like comma expressions,
It's sometimes a useful thing to do. But every usage of the
On 16.05.2016 22:10, Andrei Alexandrescu wrote:
I bring
up our very own Phobos sum algorithm, which was re-implemented later
with the Kahan method to reduce precision loss.
Kahan is clear, ingenous, and understandable and a great part of the
stdlib. I don't see what the point is here. Naive
On 17.05.2016 16:24, Steven Schveighoffer wrote:
But of course, if I want to know what type the expression x.foo will
yield, I have to do the above.
typeof((()=>x.foo)())
(Arguably, function types should not even exist and typeof(x.foo) should
give you what you want.)
On 16.05.2016 06:26, Walter Bright wrote:
Incidentally, I made the mistake of mentioning this thread (due to my
astonishment that CTFE ignores float types)
Float types are not selected because they are less accurate,
(AFAIK, accuracy is a property of a value given some additional context.
On 09.05.2016 22:20, Walter Bright wrote:
On 5/9/2016 12:39 PM, tsbockman wrote:
Educating programmers who've never studied how to write correct FP
code is too
complex of a task to implement via compiler warnings. The warnings
should be
limited to cases that are either obviously wrong, or where
On 16.05.2016 17:11, Daniel Murphy wrote:
On 16/05/2016 10:37 PM, Walter Bright wrote:
Some counter points:
1. Go uses 256 bit soft float for constant folding.
Then we should use 257 bit soft float!
I don't see how you reach that conclusion, as 258 bit soft float is
clearly superior.
On 16.05.2016 07:49, Max Samukha wrote:
On Monday, 16 May 2016 at 04:02:54 UTC, Manu wrote:
extended x = 1.3;
x + y;
If that code were to CTFE, I expect the CTFE to use extended precision.
My point is, CTFE should surely follow the types and language
semantics as if it were runtime generated
On 16.05.2016 00:34, Walter Bright wrote:
Yes. Algorithms can break because of it.
So far, nobody has posted a legitimate one (i.e. not contrived).
My examples were not contrived. Manu's even less so.
What you call "illegitimate" are really just legitimate examples that
you dismiss
On 14.05.2016 00:13, QAston wrote:
About != being unintuitive - do you remember unicode for notequals sign?
I don't, i prefer something that's actually on my keyboard.
There's really no reason to.
I simply type \neq in my text editor in order to get ≠.
(And M-x xx gives me the corresponding
On 13.05.2016 23:21, Georgi D wrote:
Hi,
I have the following code which should compile in my opinion:
struct Foo {}
import std.range.primitives;
import std.algorithm.iteration : map, joiner;
auto toChars(R)(R r) if (isInputRange!R)
{
return r.map!(toChars).joiner(", ");
}
auto
On 13.05.2016 23:35, Walter Bright wrote:
On 5/13/2016 12:48 PM, Timon Gehr wrote:
IMO the compiler should never be allowed to use a precision different
from the one specified.
I take it you've never been bitten by accumulated errors :-)
...
If that was the case it would be because I
On 14.05.2016 02:49, Timon Gehr wrote:
result can actually be made less precise
less accurate. I need to go to sleep.
On 14.05.2016 02:49, Timon Gehr wrote:
IEE
IEEE.
On 17.05.2016 23:07, Walter Bright wrote:
On 5/17/2016 11:08 AM, Timon Gehr wrote:
Right. Hence, the 80-bit CTFE results have to be converted to the final
precision at some point in order to commence the runtime computation.
This means
that additional rounding happens, which was not present in
I had written and sent this message three days ago, but it seemingly
never showed up on the newsgroup. I'm sorry if it seemed that I didn't
explain myself, I was operating under the assumption that this message
had been made available to you.
On 14.05.2016 03:26, Walter Bright wrote:
> On
On 17.05.2016 21:31, deadalnix wrote:
On Tuesday, 17 May 2016 at 18:08:47 UTC, Timon Gehr wrote:
Right. Hence, the 80-bit CTFE results have to be converted to the
final precision at some point in order to commence the runtime
computation. This means that additional rounding happens, which was
On 15.05.2016 05:02, Joe Duarte wrote:
Type systems are quite arbitrary and primitive
That may apply to the popular ones.
-- we could've moved to real-world types
The "real world" is complex and there are bound to be some modeling
limitations. I don't really see what "real-world" type is
On 15.05.2016 01:42, Joe Duarte wrote:
Note also that I saw myself as being a bit *charitable* to C by choosing
that sample. For instance, I didn't use an example littered with the
word "void". Void in English most commonly means invalid, canceled, or
not binding, as in a voided check, a void
On 02.05.2016 19:31, Adam D. Ruppe wrote:
On Monday, 2 May 2016 at 15:52:34 UTC, Xinok wrote:
I'm proposing that we add a warning to the compiler for this
particular case. If the programmer intended to return a lambda, then
rewrite the expression as one of:
I agree, forcing people to rewrite
On 02.05.2016 22:20, Adam D. Ruppe wrote:
On Monday, 2 May 2016 at 20:11:53 UTC, Timon Gehr wrote:
I don't think { ... } as shorthand for (){ ... } is necessary or
particularly useful in the first place.
Indeed. I don't think =>x as a shorthand for {return x;} is really worth
it either... D
As there has been some interest at DConf, I have pushed the experimental
D frontend I have been hacking on to github under the boost licence (for
compatibility with DMD).
https://github.com/tgehr/d-compiler
It is not yet feature-complete (e.g. constructors, destructors,
exception
On 10.05.2016 15:53, Meta wrote:
Do you like comma expressions, and think its presence in the language
is more pro than con ?
It should've been killed off a long time ago. It only causes bugs and
can easily be replaced with a library feature if necessary. I think
Andrei suggested that it
On 09.05.2016 11:24, Stefan Koch wrote:
At Dconf Manu asked to use pow expressions at CTFE.
Luckily he can.
powExpressions work at ctfe.
enum x=2.4^^4.5;
DMD master:
./../../phobos/std/math.d(4857): Error: cannot convert to ushort*
at compile time
./../../phobos/std/math.d(6113):
On 14.04.2016 23:24, Steven Schveighoffer wrote:
But the first error seems tailored to apply to this situation. My
question is, why? What harm are we fixing by preventing return type
inference in overriding functions?
AFAIK it's supposed to work, but it is currently not supported by DMD:
On 15.04.2016 17:22, Steven Schveighoffer wrote:
On 4/14/16 11:10 PM, Andrei Alexandrescu wrote:
Consider:
https://github.com/D-Programming-Language/phobos/blob/master/std/range/primitives.d#L152
It works around a limitation of inout that isn't necessary (even though
I thought it was being
On 15.04.2016 22:03, Steven Schveighoffer wrote:
On 4/15/16 3:48 PM, Timon Gehr wrote:
On 15.04.2016 17:22, Steven Schveighoffer wrote:
On 4/14/16 11:10 PM, Andrei Alexandrescu wrote:
Consider:
https://github.com/D-Programming-Language/phobos/blob/master/std/range/primitives.d#L152
It
On 15.04.2016 23:56, Steven Schveighoffer wrote:
On 4/15/16 5:17 PM, Timon Gehr wrote:
On 15.04.2016 22:47, Steven Schveighoffer wrote:
There's no difference between a function that declares its variables
inout within its parameters or one that declares them locally.
...
Yes, there is.
On 15.04.2016 22:47, Steven Schveighoffer wrote:
On 4/15/16 4:27 PM, Timon Gehr wrote:
On 15.04.2016 22:03, Steven Schveighoffer wrote:
On 4/15/16 3:48 PM, Timon Gehr wrote:
On 15.04.2016 17:22, Steven Schveighoffer wrote:
On 4/14/16 11:10 PM, Andrei Alexandrescu wrote:
Consider:
On 15.04.2016 23:03, Andrei Alexandrescu wrote:
On 04/15/2016 04:47 PM, Steven Schveighoffer wrote:
There's no difference between a function that declares its variables
inout within its parameters or one that declares them locally.
So now we get to things like:
void fun() {
inout int
On 18.04.2016 00:08, Bauss wrote:
On Sunday, 17 April 2016 at 21:59:38 UTC, Timon Gehr wrote:
On 17.04.2016 23:49, Bauss wrote:
On Sunday, 17 April 2016 at 21:23:58 UTC, Timon Gehr wrote:
mixin(generate());
pragma(msg,generate());
That's not a solution to the problem, because you will be
On 17.04.2016 18:44, Nick Treleaven wrote:
I think @property is OK.
No, it isn't:
import std.stdio;
struct S{
@property int delegate() foo(){ return ()=>3; }
}
void main(){
S s;
writeln(s.foo()); // "int delegate()"
}
On 17.04.2016 23:18, Bauss wrote:
Can there please be implemented something to retrieve the generated
mixins that causes compiler errors; like perhaps a flag you pass that
will print all mixins with compiler errors?
Sometimes when you create highly dynamic mixins it can be hard to
identify
On 17.04.2016 23:49, Bauss wrote:
On Sunday, 17 April 2016 at 21:23:58 UTC, Timon Gehr wrote:
mixin(generate());
pragma(msg,generate());
That's not a solution to the problem, because you will be printing ALL
mixins and not just the ones causing compilation errors.
Obviously you'll insert
On 15.04.2016 05:10, Andrei Alexandrescu wrote:
Consider:
https://github.com/D-Programming-Language/phobos/blob/master/std/range/primitives.d#L152
...
Related: Phobos should never use is(typeof(...)). Contrary to popular
belief, is(typeof(...)) is not the same as __traits(compiles,...).
On 15.04.2016 11:07, Timon Gehr wrote:
... Most of Phobos code assumes that ranges be struct fields.
Most of Phobos assumes that ranges can be
The fundamental problem is that inout is disallows certain kinds of
composition. ...
inout disallows
901 - 1000 of 1775 matches
Mail list logo
