On 5/1/16 7:58 PM, Seb wrote:
On Friday, 15 April 2016 at 23:05:14 UTC, Steven Schveighoffer wrote:
On 4/15/16 6:31 PM, Timon Gehr wrote:
[...]
I'm sorry, should have put on my standard disclaimer that I am not a
compiler writer :) I actually have no idea how this is done in the
compiler, jus
On Friday, 15 April 2016 at 23:05:14 UTC, Steven Schveighoffer
wrote:
On 4/15/16 6:31 PM, Timon Gehr wrote:
[...]
I'm sorry, should have put on my standard disclaimer that I am
not a compiler writer :) I actually have no idea how this is
done in the compiler, just how a compiler should behav
On Monday, 18 April 2016 at 00:53:26 UTC, Temtaime wrote:
shared currently is useless too tbw
shared did catch bugs in phobos and user code, that would
otherwise sneak in.
On Sunday, 17 April 2016 at 17:39:48 UTC, QAston wrote:
First @property + compiler switch, now @property + deprecated
switch. When should I use property? For all the getters? Should
I start with property or with member access? Does it even
matter because of optional parens? Why do I even need t
On Monday, 18 April 2016 at 08:53:31 UTC, Guillaume Piolat wrote:
And shared and @property :)
I still want to see @property fixed rather than removed - the
edge case with returning a delegate is an interesting one to me
(though that's ALL I want it to do, leave everything else alone)
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 Monday, 18 April 2016 at 08:52:19 UTC, Guillaume Piolat wrote:
Personnally I wish synchronized, comma operator, and actively
harmful things would go. nothrow provides little value, but no
negative value.
And shared and @property :)
But I guess this isn't Christmas already.
On Sunday, 17 April 2016 at 23:03:26 UTC, Adam D. Ruppe wrote:
On Sunday, 17 April 2016 at 21:20:49 UTC, Timon Gehr wrote:
On 17.04.2016 18:44, Nick Treleaven wrote:
I think @property is OK.
No, it isn't:
Seriously, @property is one of the biggest SNAFUs of the
language.
I think I'll wr
On Sunday, 17 April 2016 at 23:03:26 UTC, Adam D. Ruppe wrote:
On Sunday, 17 April 2016 at 21:20:49 UTC, Timon Gehr wrote:
On 17.04.2016 18:44, Nick Treleaven wrote:
I think @property is OK.
No, it isn't:
Seriously, @property is one of the biggest SNAFUs of the
language.
Today I learn
On Sunday, 17 April 2016 at 23:03:26 UTC, Adam D. Ruppe wrote:
On Sunday, 17 April 2016 at 21:20:49 UTC, Timon Gehr wrote:
On 17.04.2016 18:44, Nick Treleaven wrote:
I think @property is OK.
No, it isn't:
Seriously, @property is one of the biggest SNAFUs of the
language.
I think I'll wr
On Sunday, 17 April 2016 at 21:20:49 UTC, Timon Gehr wrote:
On 17.04.2016 18:44, Nick Treleaven wrote:
I think @property is OK.
No, it isn't:
Seriously, @property is one of the biggest SNAFUs of the language.
I think I'll write an editorial about this stuff in TWID tonight.
(I'm also very
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 19:39, QAston wrote:
First @property + compiler switch, now @property + deprecated switch.
When should I use property? For all the getters? Should I start with
property or with member access? Does it even matter because of optional
parens? Why do I even need to care about this?
@p
On Sunday, 17 April 2016 at 16:44:50 UTC, Nick Treleaven wrote:
The @safe troika is a good design (except @safe should be the
default), the implementation is lacking though. Ideallists want
to make @safe strict now, but break code sometimes even without
basic workarounds for memory-safe code. P
On Sunday, 17 April 2016 at 14:30:59 UTC, QAston wrote:
You've got lucky with pure (modulo corner cases) and ctfe, much
less lucky with @safe, @trusted, @system, inout, shared, scope,
property.
The @safe troika is a good design (except @safe should be the
default), the implementation is lacki
On Friday, 15 April 2016 at 20:03:07 UTC, Andrei Alexandrescu
wrote:
We should really do away with the cowboy style of designing
language, which sadly Walter and I have been guilty of too
often in the past. The slow but sure accretion of complexity of
inout is a textbook example of where that l
On Saturday, 16 April 2016 at 22:06:10 UTC, Marco Leise wrote:
Am Fri, 15 Apr 2016 09:44:05 -0400
schrieb Andrei Alexandrescu :
inout must go. -- Andrei
Ceterum censeo Carthaginem esse delendam. -- Marcus Porcius Cato
:o)
What does that have to do with what he said?
Are you comparing him to C
Am Fri, 15 Apr 2016 09:44:05 -0400
schrieb Andrei Alexandrescu :
inout must go. -- Andrei
Ceterum censeo Carthaginem esse delendam. -- Marcus Porcius Cato
:o)
--
Marco
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 return, in T[] slice, in T[]
replacement);
If the function is passed
(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 2016-04-15 07:38, Andrei Alexandrescu wrote:
I think we should deprecate inout. For real. It costs way too much for
what it does. For all I can tell most of D's proponents don't know how
it works. -- Andrei
If "inout" is only used as a way avoid code duplication, both when
writing the code
On 15/04/2016 04:10, Andrei Alexandrescu wrote:
Commenting it out yields a number of unittest compilation errors,
neither informative about the root of the problem and indicative as to
how the parameter solves it.
...
2. There needs to be documentation for people working on the standard
library
On 4/15/16 6:31 PM, Timon Gehr wrote:
On 15.04.2016 23:56, Steven Schveighoffer wrote:
Impossible or difficult to do with the current implementation?
...
What I'm saying is that the check that is currently implemented is not
adequate for the new case. This is not terribly important though. Th
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. Seman
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. Semantic analysis sees the parameter types before it se
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 ohHel
On 04/15/2016 05:17 PM, Timon Gehr wrote:
Well, that is precisely the way that languages with real type systems
address issues like this one. D has many others like it.
Note that for type systems, complexity and expressiveness do not
necessarily correlate.
Nicely put on both counts. (Well "rea
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:
https://gi
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 ohHello = 42;
...
}
How to explain such a construct?
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:
https://github.com/D-Programming-Language/phobos/blob/master
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 wo
On 4/15/16 4:08 PM, Andrei Alexandrescu wrote:
On 04/15/2016 04:03 PM, Steven Schveighoffer wrote:
I have a way to make this work. This is actually the most major sticking
point in inout.
The only correct thing is to keep is that globals/static variables
cannot be typed inout.
Another special
On 4/15/16 4:03 PM, Andrei Alexandrescu wrote:
On 04/15/2016 03:44 PM, Steven Schveighoffer wrote:
I assure you, these limitations were self-imposed. I insisted on them,
without realizing that they would cause problems with generic code. I
thought they would be good "lint" detection.
https://i
On 04/15/2016 04:03 PM, Steven Schveighoffer wrote:
I have a way to make this work. This is actually the most major sticking
point in inout.
The only correct thing is to keep is that globals/static variables
cannot be typed inout.
Another special case? The only correct thing is to simplify the
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 works around a limitation of inout that isn't necessa
On 04/15/2016 03:44 PM, Steven Schveighoffer wrote:
No, because it's not sound. you cannot cast to const through 2+
indirections. However inout works there.
That is correct, a classic... thanks for getting me straight.
I think the point of Kenji's argument is that inout's current
limitations
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 h
On 4/15/16 3:28 PM, Andrei Alexandrescu wrote:
On 4/15/16 2:39 PM, Steven Schveighoffer wrote:
On 4/15/16 1:11 PM, Andrei Alexandrescu wrote:
Would it be difficult to make it work without inout?
T[] dup(T)(T[] arr)
this should be doable. Problem is, you get identical instantiations for
each
On 15-Apr-2016 08:38, Andrei Alexandrescu wrote:
On 04/15/2016 12:23 AM, Jonathan M Davis via Digitalmars-d wrote:
On Thursday, April 14, 2016 23:10:12 Andrei Alexandrescu via
Digitalmars-d
wrote:
[snip]
- Jonathan M Davis
I think we should deprecate inout. For real. It costs way too much f
On 4/15/16 2:39 PM, Steven Schveighoffer wrote:
On 4/15/16 1:11 PM, Andrei Alexandrescu wrote:
On 04/15/2016 12:19 PM, Kenji Hara via Digitalmars-d wrote:
Didn't you use array.dup until now? It's a good example to handle
qualifiers with inout.
Would it be difficult to make it work without in
On Friday, 15 April 2016 at 12:54:11 UTC, ixid wrote:
On Friday, 15 April 2016 at 03:10:12 UTC, Andrei Alexandrescu
wrote:
We want Phobos to be beautiful, a prime example of good D
code. Admittedly, it also needs to be very general and
efficient, which sometimes gets in the way. But we cannot
On 4/15/16 1:11 PM, Andrei Alexandrescu wrote:
On 04/15/2016 12:19 PM, Kenji Hara via Digitalmars-d wrote:
Didn't you use array.dup until now? It's a good example to handle
qualifiers with inout.
Would it be difficult to make it work without inout?
T[] dup(T)(T[] arr)
this should be doable
On 04/15/2016 02:24 PM, jmh530 wrote:
I had not realized that the main reason that inout was added was because
of not being able to use templates as virtual functions in classes.
The main reason is actually avoiding code duplication is such situations
(i.e. the problem has a solution just not
On Friday, 15 April 2016 at 17:11:39 UTC, Andrei Alexandrescu
wrote:
3. For all problems that inout is purported to solve, I know of
idioms that are definitely simpler and overall almost as good
if not better. So a hard question is whether the existence is
justified.
If it's something to be
On 04/15/2016 12:19 PM, Kenji Hara via Digitalmars-d wrote:
Didn't you use array.dup until now? It's a good example to handle
qualifiers with inout.
Would it be difficult to make it work without inout?
It's not sensible at all, inout is already well-defined and has much
power in D's type sys
2016-04-15 22:41 GMT+09:00 Andrei Alexandrescu via Digitalmars-d <
digitalmars-d@puremagic.com>:
> On 04/15/2016 06:50 AM, Kenji Hara via Digitalmars-d wrote:
>
>>
>>
>> You should recall the history of inout.
>> http://wiki.dlang.org/DIP2
>>
>> At first, It has designed to temporarily squash muta
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 helpful when I suggested it). That is, functions
w
On 04/15/2016 02:15 AM, Vladimir Panteleev wrote:
On Friday, 15 April 2016 at 05:38:56 UTC, Andrei Alexandrescu wrote:
I think we should deprecate inout. For real. It costs way too much for
what it does. For all I can tell most of D's proponents don't know how
it works. -- Andrei
What would re
On Friday, 15 April 2016 at 12:54:11 UTC, ixid wrote:
Why didn't we go with all functions being able to infer const,
pure etc rather than just templates?
Non-templated function may not have their source code available.
For consistency, non-template function have no inference.
On 04/15/2016 02:40 AM, Shammah Chancellor wrote:
I think that behavioral type checks are common enough in D that it
should have it's own first-class syntax.
No. -- Andrei
On 04/15/2016 02:49 AM, Walter Bright wrote:
On 4/14/2016 8:10 PM, Andrei Alexandrescu wrote:
Commenting it out yields a number of unittest compilation errors, neither
informative about the root of the problem and indicative as to how the
parameter
solves it.
https://issues.dlang.org/show_bug.
On 04/15/2016 03:42 AM, deadalnix wrote:
On Friday, 15 April 2016 at 04:23:29 UTC, Jonathan M Davis wrote:
IIRC, the problem has to do with ranges of inout elements working
correctly, which gets really funky, because inout is a temporary thing
and not a full-on type constructor/qualifier. I beli
On 04/15/2016 06:50 AM, Kenji Hara via Digitalmars-d wrote:
You should recall the history of inout.
http://wiki.dlang.org/DIP2
At first, It has designed to temporarily squash mutable/const/immutable
qualifiers on function argument inside function body. Therefore when
inout qualifier appears in
On 04/15/2016 05:07 AM, Timon Gehr wrote:
The fundamental problem is that inout is disallows certain kinds of
composition. It's a flawed language primitive.
I agree. The more I try things with it the more awfully complex and
useless it is. inout must go. -- Andrei
On Friday, 15 April 2016 at 09:07:27 UTC, Timon Gehr wrote:
Related: Phobos should never use is(typeof(...)). Contrary to
popular belief, is(typeof(...)) is not the same as
__traits(compiles,...).
I don't think it should be using __traits(compiles) either. I'd
prefer to see built from the ot
On 4/15/16 8:59 AM, Nick Treleaven wrote:
On Friday, 15 April 2016 at 04:23:29 UTC, Jonathan M Davis wrote:
Certainly, there have been a few times that it's come up in D.Learn
when folks ask what the heck it is, so there should be a few posts
floating around with an explanation. This is the only
On Friday, 15 April 2016 at 04:23:29 UTC, Jonathan M Davis wrote:
Certainly, there have been a few times that it's come up in
D.Learn when folks ask what the heck it is, so there should be
a few posts floating around with an explanation. This is the
only useful post that I could find in a quick
On Friday, 15 April 2016 at 03:10:12 UTC, Andrei Alexandrescu
wrote:
Consider:
https://github.com/D-Programming-Language/phobos/blob/master/std/range/primitives.d#L152
There is no explanation to it in the source code, and the line
blames to
https://github.com/D-Programming-Language/phobos/pul
On Friday, 15 April 2016 at 03:10:12 UTC, Andrei Alexandrescu
wrote:
We want Phobos to be beautiful, a prime example of good D code.
Admittedly, it also needs to be very general and efficient,
which sometimes gets in the way. But we cannot afford an
accumulation of mad tricks to obscure the lar
2016-04-15 14:38 GMT+09:00 Andrei Alexandrescu via Digitalmars-d <
digitalmars-d@puremagic.com>:
> On 04/15/2016 12:23 AM, Jonathan M Davis via Digitalmars-d wrote:
>
>> On Thursday, April 14, 2016 23:10:12 Andrei Alexandrescu via Digitalmars-d
>> wrote:
>>
>>> Consider:
>>>
>>>
>>> https://github
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
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,...).
vo
On Friday, 15 April 2016 at 05:38:56 UTC, Andrei Alexandrescu
wrote:
I think we should deprecate inout. For real. It costs way too
much for what it does. For all I can tell most of D's
proponents don't know how it works. -- Andrei
This is the explanation I came up with, not sure if accurate.
On Friday, 15 April 2016 at 04:23:29 UTC, Jonathan M Davis wrote:
IIRC, the problem has to do with ranges of inout elements
working correctly, which gets really funky, because inout is a
temporary thing and not a full-on type constructor/qualifier. I
believe that Kenji is the one that implement
On Friday, 15 April 2016 at 07:33:42 UTC, w0rp wrote:
I think it has something to do with making the function, in
this case a lambda, inout, so that it can accept inout types.
Then the typeof bit is a weird way to writing something like
__traits(compiles, ...) , because functions which have no
I think it has something to do with making the function, in this
case a lambda, inout, so that it can accept inout types. Then the
typeof bit is a weird way to writing something like
__traits(compiles, ...) , because functions which have no type
result in void, and that fails the typeof check.
On 4/14/2016 8:10 PM, Andrei Alexandrescu wrote:
Commenting it out yields a number of unittest compilation errors, neither
informative about the root of the problem and indicative as to how the parameter
solves it.
https://issues.dlang.org/show_bug.cgi?id=15926
On Friday, 15 April 2016 at 03:10:12 UTC, Andrei Alexandrescu
wrote:
Consider:
https://github.com/D-Programming-Language/phobos/blob/master/std/range/primitives.d#L152
There is no explanation to it in the source code, and the line
blames to
https://github.com/D-Programming-Language/phobos/pul
On Friday, 15 April 2016 at 05:38:56 UTC, Andrei Alexandrescu
wrote:
I think we should deprecate inout. For real. It costs way too
much for what it does. For all I can tell most of D's
proponents don't know how it works. -- Andrei
What would replace it in the case of classes, where you can't
On 04/15/2016 12:23 AM, Jonathan M Davis via Digitalmars-d wrote:
On Thursday, April 14, 2016 23:10:12 Andrei Alexandrescu via Digitalmars-d
wrote:
Consider:
https://github.com/D-Programming-Language/phobos/blob/master/std/range/primi
tives.d#L152
There is no explanation to it in the source co
On Thursday, April 14, 2016 23:10:12 Andrei Alexandrescu via Digitalmars-d
wrote:
> Consider:
>
> https://github.com/D-Programming-Language/phobos/blob/master/std/range/primi
> tives.d#L152
>
> There is no explanation to it in the source code, and the line blames to
> https://github.com/D-Programm
On Friday, 15 April 2016 at 03:10:12 UTC, Andrei Alexandrescu
wrote:
Consider:
https://github.com/D-Programming-Language/phobos/blob/master/std/range/primitives.d#L152
There is no explanation to it in the source code, and the line
blames to
https://github.com/D-Programming-Language/phobos/pul
72 matches
Mail list logo
