On Wednesday, 11 May 2016 at 13:29:56 UTC, Gopan wrote:
int x;
while( scanf("%d", ), x!= 0) // until user input 0.
{
//do something with x
}
Without the comma operator, I would have to repeat the scanf
statement.
int x;
scanf("%d", );
while(x != 0)
{
//do something with x
On 10/05/2016 12:12, Tomer Filiba wrote:
Alternatively, an isVersion(x) predicate that I could use in a static if
could do the trick -- although I think ``version(x || y)`` is more
readable than ``static if (isVersion(x) || isVersion(y))``
This is actually longer for 2 arguments, but can scale
On Friday, 6 May 2016 at 23:51:59 UTC, Steven Schveighoffer wrote:
Of COURSE D supports local ref variables:
struct RefVar(T)
{
private T * var;
this(ref T v) { var = }
auto get() { return *var; }
alias this get;
}
ref get() return {...
Which is unsafe even if the ctor is marked
On Thursday, 28 April 2016 at 22:37:41 UTC, H. S. Teoh wrote:
I find for(;;) far more logical than other vacuous workarounds
like
while(1) or while(true).
It's only because of C that all the for arguments can be left
out, I'd rather have:
while {...}
I.e. it defaults to true. 'A while' is
On Friday, 29 April 2016 at 06:27:07 UTC, Jacob Carlborg wrote:
In an ideal world the language would support trailing delegate
syntax allowing this to work without any language support:
forever {
}
Translated to:
forever({
});
Or maybe with macros supporting a trailing statement as the
On Thursday, 28 April 2016 at 19:45:47 UTC, Steven Schveighoffer
wrote:
If you don't want to mutate it, don't put var in the parameter
name. I put var there because I wanted to mutate it. Swift
requires that already. It just now won't let you do it in the
parameter declaration, you have to
On Thursday, 28 April 2016 at 18:49:54 UTC, Steven Schveighoffer
wrote:
1. Swift 3 will no longer allow mutable variables as
parameters. Instead, your parameters will be immutable, or
reference (inout). To fix this, you can assign your immutable
variable to a mutable one (immutability is
On 25/04/2016 11:16, Nick Treleaven wrote:
On Friday, 22 April 2016 at 19:09:40 UTC, David Nadlinger wrote:
alias Instantiate(alias Template, Params...) = Template!Params;
Ah, maybe I'd even seen this in passing and forgot. Good point about
aliasSeq template elements, let's make this public.
On Friday, 22 April 2016 at 19:09:40 UTC, David Nadlinger wrote:
From std.meta:
---
/*
* Instantiates the given template with the given list of
parameters.
*
* Used to work around syntactic limitations of D with regard
to instantiating
* a template from an alias sequence (e.g. T[0]!(...)
On Saturday, 23 April 2016 at 20:50:31 UTC, Adam D. Ruppe wrote:
I still can't get over the ridiculous grey constraints. WTF.
It's much better reading signatures than before.
But what we could do is add a margin-bottom to them if needed,
while keeping the others hugged up.
Good idea,
On Friday, 15 April 2016 at 18:46:01 UTC, Steven Schveighoffer
wrote:
inout(T)[] overlap(T)(inout(T)[] r1, inout(T)[] r2)
Might be nice if inout applied to template parameter types:
T[] overlap(inout T)(T[] r1, T[] r2);
If it wasn't for the virtual function issue, I wonder if inout
would
On 22/04/2016 14:40, Steven Schveighoffer wrote:
OK, I get it. I think this used to work, but I think D has long since
disallowed direct access to eponymous members.
So what you really want to do is:
staticEx!(Exception, msg)!(file, line), but of course this doesn't
follow proper grammar.
I
On 21/04/2016 18:03, Steven Schveighoffer wrote:
This doesn't work?
alias staticEx(string msg, string file = __FILE__, size_t line =
__LINE__) = staticEx!(Exception, msg).staticEx!(file, line);
No, nor using the module dot prefix `= .staticEx!(...).staticEx` either:
staticex.d(3): Error:
Hi,
There doesn't seem to be something like this in Phobos:
alias Instantiate(alias Template, T...) = Template!T;
Here's an example of why I need it:
alias staticEx(string msg, string file = __FILE__, size_t line =
__LINE__) =
Instantiate!(.staticEx!(Exception, msg), file, line);
On Wednesday, 20 April 2016 at 19:32:01 UTC, Basile Burg wrote:
a system exist to throw @nogc exceptions that would work in
this case (the message doesn't have to be customized so it can
be static):
@nogc @safe
void throwStaticEx(T, string file = __FILE__, size_t line =
__LINE__)()
{
On Tuesday, 19 April 2016 at 13:34:24 UTC, John Colvin wrote:
On Tuesday, 19 April 2016 at 13:05:35 UTC, tcak wrote:
I would recommend making a copy of the whole repository locally
before any of that just in case you mess something up, at least
while you're not as confident with git.
Isn't
On Friday, 15 April 2016 at 17:24:19 UTC, Andrei Alexandrescu
wrote:
inout(T)[] overlap(T)(inout(T)[] r1, inout(T)[] r2) @trusted
BTW, why is overlap undocumented - is ctfe support a good enough
reason?
https://github.com/dlang/phobos/blob/v2.071.0/std/array.d#L715
I've thought about
On Sunday, 17 April 2016 at 12:05:03 UTC, Anonymous5 wrote:
If attributes are well split into sub categories, we could
justify that a sub category will have @ and another not (e.g
protection attributes: not @, functions attributes: @).
The list of attributes that's not classified is:
+
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
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
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
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
On Friday, 8 April 2016 at 10:11:43 UTC, Rene Zwanenburg wrote:
On Friday, 8 April 2016 at 09:56:41 UTC, Nick Treleaven wrote:
If the comparison with b shouldn't be allowed, I suggest we
add opEquals to std.range.only. This removes a need to import
std.algorithm.equal and reduces bracket
On Tuesday, 5 April 2016 at 14:00:46 UTC, ag0aep6g wrote:
I'm not sure if the new syntax is worth adding, though.
`T{...}` (or `T[...]`) saves just one character over `T!(...)`.
The latter can be done without touching the language. For the
value tuple, one can do `alias t =
On Friday, 8 April 2016 at 03:14:40 UTC, Xinok wrote:
On Friday, 8 April 2016 at 01:36:18 UTC, rcorre wrote:
@nogc unittest {
int[2] a = [1, 2];
assert(a == [1, 2]); // OK
immutable(int)[2] b = [1, 2];
assert(b == [1, 2]); // fail: array literal may cause
allocation
}
Is
On Wednesday, 23 March 2016 at 17:43:07 UTC, Tamas wrote:
On Wednesday, 23 March 2016 at 17:29:55 UTC, Nick Treleaven
wrote:
On Monday, 21 March 2016 at 23:09:27 UTC, Tamas wrote:
On Monday, 21 March 2016 at 11:48:52 UTC, Seb wrote:
Could you try to point out whats wrong with map & filter?
On Monday, 21 March 2016 at 23:09:27 UTC, Tamas wrote:
On Monday, 21 March 2016 at 11:48:52 UTC, Seb wrote:
Could you try to point out whats wrong with map & filter?
It's hard to do stuff like this:
assert(9.iota.emit!(int,(put,a){if(a%2) put(a*a); if(a%3==0)
On Monday, 21 March 2016 at 14:51:48 UTC, Vincent R wrote:
version( CRuntime_Glibc ) || version( FreeBSD ) || version
(Solaris)
{
As a workaround, you can do it with static if and version strings:
http://forum.dlang.org/post/op.vkshabecot0hzo@las-miodowy
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).
http://dlang.org/phobos/std_range.html#.chain
On 14/03/2016 11:32, thedeemon wrote:
filter_map : ('a -> 'b option) -> 'a t -> 'b t
"filter_map f e returns an enumeration over all elements x such as f y
returns Some x, where y is an element of e."
It is really convenient and comes handy in many situations. However it
requires some common
On 20/03/2016 16:57, Nick Treleaven wrote:
void opCall(ARGS...)(void delegate(ARGS) call, ARGS args)
{
stack.put(() => call(args));
}
Maybe this method would be nice (does the same thing):
Deferrer d;
...
d.capture!writeln("i = ", i);
The name capture makes it clearer
On 20/03/2016 16:18, Bauss wrote:
defer((int i) => writeln(i), i);
If it was defer(() => writeln(i)), would that do the same? (Dpaste
won't seem to let me edit your example on my tablet).
(or on my laptop)
No that's not the same, since the reference to i does not change when
doing:
On Saturday, 19 March 2016 at 23:16:40 UTC, Xinok wrote:
I took a quick look through Phobos but didn't see anything
similar so I wrote this as a proof of concept and to elicit
discussion. This also works should the function throw rather
than return gracefully.
From the thread about Kotlin and null safety:
http://forum.dlang.org/post/yxfdycdtgdesbsozv...@forum.dlang.org
On Tuesday, 23 February 2016 at 06:49:46 UTC, Tobias Müller wrote:
rsw0x wrote:
D has this too, but only for nullable types afaik.
if(byte* ptr =
On Tuesday, 23 February 2016 at 11:04:31 UTC, Nick Treleaven
wrote:
Assuming we don't want to disallow slice.ptr in @safe code,
maybe we could have the compiler insert this code before
reading slice.ptr:
version(D_NoBoundsChecks) else
if (slice.length == 0) throw new RangeError("Unsafe
On Friday, 19 February 2016 at 19:00:35 UTC, H. S. Teoh wrote:
Here's an existing one that plugs another hole in the cheese
grater:
https://github.com/D-Programming-Language/phobos/pull/4009
That pull mentions the issue of *arr[$..$].ptr being unsafe:
On Monday, 22 February 2016 at 17:28:03 UTC, Guillaume Chatelet
wrote:
static make() {
The return type is missing for the make() function:
I'm pretty sure static here works just like 'static auto'. In D I
think you can use storage classes (and even attributes) to imply
auto:
const
On Sunday, 21 February 2016 at 15:03:39 UTC, Marc Schütz wrote:
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
From the DIP:
The second rule (@system)
On Sunday, 21 February 2016 at 15:03:39 UTC, Marc Schütz wrote:
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
BTW the Usage section still uses lazy. I think
On Tuesday, 16 February 2016 at 10:32:45 UTC, Timon Gehr wrote:
struct S{
int[] a;
void foo()headconst{
a[0]=1; // ok
// arr.length=2 // error
}
}
void main(){
headconst(S) s([0,2,3]);
s.foo();
assert(s.a==[1,2,3]);
}
How to do this in the library?
On Friday, 29 January 2016 at 15:38:26 UTC, Benjamin Thaut wrote:
On Friday, 29 January 2016 at 13:38:20 UTC, Tomer Filiba wrote:
I can change all such invocations into ``func(FooPtr(null))``
but it's tedious and basically requires me to compile tens of
times before I'd cover everything. Is
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
I agree Flag is a bit ugly to use, but IIUC this proposal does
not enforce the use of a
On Tuesday, 19 January 2016 at 04:53:01 UTC, Vladimir Panteleev
wrote:
On Monday, 18 January 2016 at 20:51:23 UTC, Nick Treleaven
wrote:
This would really help on my nexus tablet, it's painful
selecting a text block of lines that flow off the visible
screen.
Where does that happen?
Sorry,
Thanks for developing the forum software.
One feature request: if there's selected text in the message body
when clicking reply, only quote the selected text rather than the
whole message body. This is what my email client does.
This would really help on my nexus tablet, it's painful
On Monday, 18 January 2016 at 15:36:09 UTC, Manu wrote:
One more time...
Assuming:
void func(const CustomString , const CustomString );
void func(ref const(CustomString) s1, ref const(CustomString)
s2);
C++:
func("hello", "world");
D:
auto dumb_name = CustomString("hello");
auto
On 16/04/2015 18:25, Nick Treleaven wrote:
I think this works:
import std.range : only;
app.put(only(foo, var, bar));
OK, that doesn't work, and an array doesn't either (which was my
assumption):
app.put([foo, var, bar]); // NG
If it had, I thought only might be more efficient than
On Wednesday, 15 April 2015 at 20:40:04 UTC, Márcio Martins wrote:
I guess chain could work in some cases, and are not that bad on
the aesthetic side, I supposed. However having to include
std.range just for that, and more importantly, all parameters
having to be the same type, as opposed to
On 18/03/2015 14:45, H. S. Teoh via Digitalmars-d wrote:
On Wed, Mar 18, 2015 at 07:45:54PM +1100, Daniel Murphy via Digitalmars-d wrote:
Kagamin wrote in message news:pltiewdojqrmgxrwh...@forum.dlang.org...
The compiler lexer can be of arbitrary complexity, because it's
already written. If
On 17/03/2015 03:28, Andrei Alexandrescu wrote:
On a higher level: there's no subset of the language that's at the same
time sufficiently complex and sufficiently obscure to make its removal a
net positive.
q delimited strings. No one uses them (used once in all of Phobos).
They are obscure
On 16/03/2015 14:17, Zach the Mystic wrote:
char* fun(return const char* x);
Compiler has enough information to adjust the return type of `fun()` to
that of input `x`. This assumes return parameters have been generalized
to all reference types. Destroy.
inout can be used for local variables
On 17/03/2015 01:45, Daniel Murphy wrote:
Nick Treleaven wrote in message news:me6jo4$ca$1...@digitalmars.com...
0b1010 binary literals (even though C++11 supports them)
0xABCD hex literals (but useful for porting C)
You can take them when you pry them from my cold, dead hands. These are
On 17/03/2015 11:34, Biotronic wrote:
On Monday, 16 March 2015 at 12:53:24 UTC, Nick Treleaven wrote:
0b1010 binary literals (even though C++11 supports them)
0xABCD hex literals (but useful for porting C)
And while we're at it, why not remove those pesky base-10
literals as well? Shouldn't
On 17/03/2015 10:31, Almighty Bob wrote:
It's far more useful for csvReader to return a type I know and
can use than it is to obscure the return type for the sake of
some philosophical ideal of increasing encapsulation.
Part of the art of API design is to hide implementation where it's not
On 17/03/2015 12:42, Daniel Murphy wrote:
Nick Treleaven wrote in message news:me950a$2boc$1...@digitalmars.com...
On 17/03/2015 03:28, Andrei Alexandrescu wrote:
On a higher level: there's no subset of the language that's at the same
time sufficiently complex and sufficiently obscure to
On 15/03/2015 19:46, Walter Bright wrote:
Any other ideas on things that can removed from the core language and
replaced with library entities?
0b1010 binary literals (even though C++11 supports them)
0xABCD hex literals (but useful for porting C)
Also, there are some things which I think are
On 15/03/2015 19:11, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net
wrote:
On Sunday, 15 March 2015 at 17:31:17 UTC, Nick Treleaven wrote:
I too want a scope attribute e.g. for safe slicing of static arrays,
etc. I'm not sure if it's too late for scope by default though, perhaps.
If we get
On 16/03/2015 04:00, Zach the Mystic wrote:
struct RC(T) if(is(T == class)) {
scope T payload;
T borrow() return {// `return` applies to `this`
return payload;
}
}
...
Also, what exactly does the `scope` on T payload get you?
It means if you forget the `return`
On 16/03/2015 14:22, Kagamin wrote:
On Monday, 16 March 2015 at 12:53:24 UTC, Nick Treleaven wrote:
/++/ - If we made /**/ nest, /++/ would be unnecessary
I'd just drop nested comments: block comments and version(none) are good
enough.
They need to nest in order to allow block comments in
On 15/03/2015 05:06, Walter Bright wrote:
In D we have some implicit casts also because the cast(int)x syntax is
dangerous. But now we can write safe casts with the int(x) syntax,
so there's
less need of naked implicit casts.
Again, too many casts can cause bugs.
You can have safe wrappers
On 15/03/2015 14:10, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net
wrote:
Here's the new version of my scope proposal:
http://wiki.dlang.org/User:Schuetzm/scope2
It's still missing real-life examples, a section on the implementation,
and a more formal specification, as well as a discussion of
On 12/03/2015 10:14, monarch_dodra wrote:
On Wednesday, 11 March 2015 at 17:23:15 UTC, welkam wrote:
Observation Nr. 1
People prefer to write var++ instead of ++var.
The root of your reasoning stems from this observation, which I
argue is wrong.
The recommendation has always been to chose
On 04/03/2015 08:55, Ivan Timokhin wrote:
void main()
{
auto arr = RCArray!int([0]);
foo(arr, arr[0]);
}
void foo(ref RCArray!int arr, ref int val)
{
{
auto copy = arr; //arr's (and copy's) reference counts are both 2
On 03/03/2015 13:05, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net
wrote:
The bigger problem is that it's relying on a convention. The RC wrapper
needs to be constructed in a particular way that's easy to get wrong and
that the compiler has no way to check for us.
Maybe the compiler could
On 26/02/2015 22:04, Andrei Alexandrescu wrote:
On 2/26/15 2:03 PM, Brian Schott wrote:
The DIP states that Any attributes are allowed on these methods., but
later states The complexity of this code underlies the importance of
making opAddRef and especially opRelease nothrow. Should the DIP
Hi,
The following code is supposed to destroy the struct instance:
import std.stdio;
struct S{
~this(){destruct.writeln;}
}
auto p = new S;
destroy(p);
end.writeln;
It works correctly if I use destroy(*p), but the above code could
perhaps be statically
On 19/02/2015 04:38, thedeemon wrote:
int x, y, z, age;
string name;
let (name, age) = getTuple(); // tuple
let (x,y,z) = argv[1..4].map!(to!int); // lazy range
let (x,y,z) = [1,2,3]; // array
SomeStruct s;
let (s.a, s.b) = tuple(3, piggies);
Alternatively
On 19/02/2015 17:00, Nick Treleaven wrote:
Alternatively std.typetuple.TypeTuple can be used instead of let
not for ranges and arrays though
Yes, but `tuple` overloads could be added for those.
Or not - the length isn't known at compile-time.
Tuple already
supports construction from a
On 16/02/2015 19:31, Steven Schveighoffer wrote:
Wait, isn't this OK?
struct S(T) if(is(T == int))
{
...
}
struct S(T) if(is(T == double))
{
...
}
...
They may even be in multiple modules.
Is this not overloading of types? I don't think this should be frowned
upon.
OK, so the idea
On 19/02/2015 14:59, John Colvin wrote:
On Thursday, 19 February 2015 at 13:52:29 UTC, Nick Treleaven wrote:
On 19/02/2015 04:38, thedeemon wrote:
int x, y, z, age;
string name;
let (name, age) = getTuple(); // tuple
let (x,y,z) = argv[1..4].map!(to!int); // lazy range
let (x,y,z)
On 17/02/2015 07:28, weaselcat wrote:
Would RefCounted!T being @nogc help alleviate this issue?
I think Andrei once said that was a good solution for exceptions.
I think the stumbling block is that if T contains indirections,
RefCounted calls GC.addRange on the T*, which currently violates
On 17/02/2015 16:15, Nick Treleaven wrote:
Would RefCounted!T being @nogc help alleviate this issue?
I think Andrei once said that was a good solution for exceptions.
Or rather that refcounting would be appropriate for exceptions, not
necessarily RefCounted. (The compiler can't generate
On 11/02/2015 13:52, Dicebot wrote:
Biggest problem with RefCounted is that it is a struct. Thus it is
inherently incompatible with polymorphic world.
For Unique, (which admittedly is a simpler concept), it does work with
polymorphic types, see:
On 10/02/2015 10:59, Daniel Murphy wrote:
DDMD currently relies on allocating classes on the stack with 'scope'
If something like DIP 69 is implemented, it seems we could support this
safely. Then we would only need to deprecate the scope attribute at a
class definition.
On 05/02/2015 01:50, H. S. Teoh via Digitalmars-d wrote:
On Thu, Feb 05, 2015 at 01:34:47AM +, deadalnix via Digitalmars-d wrote:
On Thursday, 5 February 2015 at 01:07:56 UTC, Andrei Alexandrescu wrote:
Would introduce an exception to our brace-on-its-line rule.
Which is already
On 05/02/2015 08:56, Kagamin wrote:
On Thursday, 5 February 2015 at 01:34:49 UTC, deadalnix wrote:
On Thursday, 5 February 2015 at 01:07:56 UTC, Andrei Alexandrescu wrote:
Would introduce an exception to our brace-on-its-line rule.
Will I start the next world war if I mention this rule is
On 30/01/2015 16:44, Kenji Hara via Digitalmars-d wrote:
immutable[][$] a2 = [[1,2], [3,4]]; // a static array of mutable
dynamic array of immutable ints
static assert(is(typeof(a2) == immutable(int)[][2]));
...
The type deduction will provide powerful way to type variables.
Yes,
On 30/01/2015 17:01, Kenji Hara via Digitalmars-d wrote:
2015-01-31 1:53 GMT+09:00 Nick Treleaven via Digitalmars-d
digitalmars-d@puremagic.com:
This version of staticArray allows the user to (optionally) specify the
element type.
How the API can replace following declaration with ?
auto
On 30/01/2015 16:44, Kenji Hara via Digitalmars-d wrote:
The new feature, I call it Partial type deduction, is not only for static
array length.
Yes, I think the other improvements are useful, but [$] is not strictly
necessary. Maybe [$] will turn out to be worth having, but I'm not sure
On 30/01/2015 14:47, Andrei Alexandrescu wrote:
The recent int[$] feature seems to fail that test. That feature, and in
fact more, can be done trivially with library code:
http://dpaste.dzfl.pl/f49a97e35974.
+1. Also discussed here:
https://issues.dlang.org/show_bug.cgi?id=8008#c8
On 30/01/2015 16:53, Nick Treleaven wrote:
This version of staticArray allows the user to (optionally) specify the
element type.
Actually, I'm having trouble implementing staticArray like that, perhaps
there are compiler issues causing problems. Using this:
T[len] staticArray(T, size_t
On 29/01/2015 17:51, Jonathan Marler wrote:
Nick I'm putting together the FAQ right now. I don't quite understand
this proposal. Could you outline it for me? I'd like to know exactly
what words would require an '@' symbol. What is the criteria for when to
use an '@' and when not to use one?
On 28/01/2015 22:44, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com wrote:
Could it be that new languages define grammars that are more robust than
the one used by C? Like Go?
We're not going to significantly change the structural syntax of D, so
it doesn't seem that
On 29/01/2015 15:54, Jonathan Marler wrote:
Like this:
abstract class MyClass { }
@abstract void myfunc();
See the inconsistency? You're gonna end up with alot of these types of
inconsistencies. In addition, you've made the rule of when to use the
'@' symbol more complex. Before it was, Use
On 27/01/2015 18:01, Jonathan Marler wrote:
On Tuesday, 27 January 2015 at 17:18:11 UTC, Nick Treleaven wrote:
On 27/01/2015 16:49, Jonathan M Davis via Digitalmars-d wrote:
abstract also applies to classes, as does final.
Yes, but they actually only affect the *functions* belonging to the
On 26/01/2015 21:20, bearophile wrote:
Walter Bright:
Previously, it's all been advocacy and break my code
Breaking the code should be justified by a worth gain. This patch is of
negative value.
It doesn't break code.
On 27/01/2015 02:27, Jonathan M Davis via Digitalmars-d wrote:
You're right. I forgot about those two. But it's still the case that the
number of function attributes that don't have @ on them is_far_ greater
than the number of those that do.
But I explained that most function attributes don't
On 27/01/2015 10:20, Jacob Carlborg wrote:
How is this change going to help when there's still a bunch of
attributes that can not be prefixed with '@', immutable, const, public
and so on?
Those can apply to variables too. We could use built-in @attributes for
functions only
On 27/01/2015 16:49, Jonathan M Davis via Digitalmars-d wrote:
abstract also applies to classes, as does final.
Yes, but they actually only affect the *functions* belonging to the
class, not the variables. A class is not a variable.
Also, if we end up adding
any new attributes later,
On 26/01/2015 11:39, Jonathan M Davis via Digitalmars-d wrote:
the increased visual
noise definitely is not.
Being able to ignore things starting with @ is useful when reading
function signatures:
@property const(T) @pure @nothrow foo(Arg arg, T bar) const ...
So @ can actually be signal
On 26/01/2015 17:07, Nick Treleaven wrote:
and inout gained @attribute syntax too
Actually inout can apply to local variables, so it shouldn't have a '@'
by my logic.
On 26/01/2015 11:39, Jonathan M Davis via Digitalmars-d wrote:
In theory, the increased consistency is welcome, but the increased visual
noise definitely is not. And if we leave in pure and nothrow without @,
then we're going to have code out there doing both, which adds to the
confusion, and
On 21/01/2015 19:15, zeljkog wrote:
And good name staticIota, unlike TypeTuple. I always wonder what is raw
tuple, TypeTuple or Tuple :)
Yes, there's a DIP to rename std.typetuple to std.meta.list. I made a
pull to do that (which goes further than the DIP), but I don't know if
the
On 30/12/2014 01:27, Adam D. Ruppe wrote:
On Tuesday, 30 December 2014 at 01:18:39 UTC, Andrei Alexandrescu wrote:
How would that achieve cross referencing?
To be clear, what your change does is make links like this work, yes?
On 30/12/2014 02:18, Vladimir Panteleev wrote:
I'm not sure using numbers to distinguish overloads is a good idea. Such
links would break easily.
Note: that isn't part of Andrei's pull.
Using numbers is the only workable way, other schemes would also break
easily, probably moreso. I
On 28/12/2014 17:09, Nick Treleaven wrote:
On 28/12/2014 14:22, Joseph Rushton Wakeling via Digitalmars-d wrote:
BTW is it just me, or are the various isSomething methods of std.traits
not having documentation generated properly? See:
http://dlang.org/phobos/std_traits.html
... and try
On 28/12/2014 17:11, Nick Treleaven wrote:
But for some reason codePoints and codeUnits are in between .encode.3
and .encode.4!
I made a start on fixing Walter's points, and fixed the above:
https://github.com/D-Programming-Language/phobos/pull/2825
On 28/12/2014 14:22, Joseph Rushton Wakeling via Digitalmars-d wrote:
BTW is it just me, or are the various isSomething methods of std.traits
not having documentation generated properly? See:
http://dlang.org/phobos/std_traits.html
... and try searching for, say, isBoolean, or isSomeString.
On 28/12/2014 01:00, Walter Bright wrote:
This is so bad there isn't even a direct link to it
With newer dmd, there should be - I get .encode.4 as the anchor name.
Thanks for merging that pull BTW.
But for some reason codePoints and codeUnits are in between .encode.3
and .encode.4!
On 28/12/2014 17:51, Russel Winder via Digitalmars-d wrote:
Trying to fix
this problem seems to require people who want to contribute to have to
clone Phobos and submit pull requests.
You can do it all from your browser if you want, check the Improve this
page link at the top right of each
On 28/12/2014 14:49, Joseph Rushton Wakeling via Digitalmars-d wrote:
Is there an existing equivalent that can be used for template
parameters? Template Params: or TemplateParams:, for example, don't
work.
You can just use Params: for them also. Perhaps separating them might be
nice though.
301 - 400 of 470 matches
Mail list logo