Not worth it, the typeof variants are fine.
Of course, "T == int" is unambiguous, but then when you can do
that and not "T == J" you'll confuse people ("the compiler knows
T and J are types...") and that rabbit hole is a dangerous one.
Mainly because it makes parsing more difficult. I am nothing if
not biased. :P
On Sat, Jun 16, 2012 at 9:18 AM, Tommi wrote:
> What do you think of adding to the language these couple of keywords just
> for syntactic sugar: This and Super. They'd be the types of this and super
> inside class and struct scope.
>
> is(This == typeof(this))
> ...and...
> is(Super == typeof(supe
On Friday, 15 June 2012 at 12:56:49 UTC, Timon Gehr wrote:
On 06/15/2012 02:19 PM, bearophile wrote:
Timon Gehr:
Why not allow equality operators to operate on types?
That's nice, of course. But is it possible?
Yes, certainly.
Not without losing the context insensitivity of the D gramma
What do you think of adding to the language these couple of
keywords just for syntactic sugar: This and Super. They'd be the
types of this and super inside class and struct scope.
is(This == typeof(this))
...and...
is(Super == typeof(super))
On 6/16/12, Andrej Mitrovic wrote:
> static auto opDispatch(string name, Params...)(Params params)
Maybe "auto ref" there actually.
On 6/14/12, Jacob Carlborg wrote:
> Is it possible, somehow, to emulate adding new _static_ methods to a
> class, something like this:
Of course there is, this is D not Java! Enjoy:
import std.stdio;
import std.metastrings;
void fooBar(T : Foo)(int x) { writeln(x); }
struct Foo
{
static au
Greetings
Is emplace/clear mechanism mature enough to be used to create freelists?
I looked but found very scanty documentation on emplace/clear on dlang.org.
Regards
- Puneet
On 6/13/2012 11:46 PM, Jacob Carlborg wrote:
Is it possible, somehow, to emulate adding new _static_ methods to a class,
something like this:
void fooBar (/*something*/, int x) {}
Making this possible:
Foo.fooBar(4);
What's the compelling use case?
On 6/15/2012 5:11 AM, Timon Gehr wrote:
Why not allow equality operators to operate on types?
Generally because of parsing problems.
On Friday, June 15, 2012 19:31:58 bearophile wrote:
> Jonathan M Davis:
> > It's the fact that enforce is lazy which prevents inlining
> > (which really does
> > need to be fixed or enforce is going to continue to be a
> > performance problem).
>
> Then my "solution" solves nothing. Thank you Jona
On 15-06-2012 19:31, bearophile wrote:
Jonathan M Davis:
It's the fact that enforce is lazy which prevents inlining (which
really does
need to be fixed or enforce is going to continue to be a performance
problem).
Then my "solution" solves nothing. Thank you Jonathan.
However, this suggest
Timon Gehr:
On 06/15/2012 02:19 PM, bearophile wrote:
Timon Gehr:
Why not allow equality operators to operate on types?
That's nice, of course. But is it possible?
Yes, certainly.
OK. Then do you know why the nice improvement you suggest was not
the design used since the beginning ins
Jonathan M Davis:
It's the fact that enforce is lazy which prevents inlining
(which really does
need to be fixed or enforce is going to continue to be a
performance problem).
Then my "solution" solves nothing. Thank you Jonathan.
However, this suggestion is clearly bad, because it's
sugges
On Friday, June 15, 2012 15:50:17 Jacob Carlborg wrote:
> On 2012-06-15 14:55, Kagamin wrote:
> > On Friday, 15 June 2012 at 12:17:32 UTC, bearophile wrote:
> >> Even if this version is not documented in Phobos docs (because the
> >> inliner someday will be better), today it allows methods that mus
On 15.06.2012 18:27, bearophile wrote:
Dmitry Olshansky:
If that is sole concern, I suggest do a pull that makes enforce vs
assert decision accessible from the outside:
NotNull!(T, NotNull.Strict) //asserts
NotNull!T //throws
Nullable isn't the only problem, there are similar problems with
s
Dmitry Olshansky:
If that is sole concern, I suggest do a pull that makes enforce
vs assert decision accessible from the outside:
NotNull!(T, NotNull.Strict) //asserts
NotNull!T //throws
Nullable isn't the only problem, there are similar problems with
std.random.uniform. How do you tell unif
On 15.06.2012 16:56, Timon Gehr wrote:
On 06/15/2012 02:18 PM, Dmitry Olshansky wrote:
On 15.06.2012 16:11, Timon Gehr wrote:
Why not allow equality operators to operate on types?
is(==) expressions tend to create bracket noise and treat the two
arguments non-uniformly.
This would suggest a l
On 15/06/12 12:48, jerro wrote:
Joseph's pull request already contains a fix for this bug but
I'm guessing it won't be merged until other issues with
randomSample are resolved.
Assuming that everyone agrees that a random sample should always lazily evaluate
to the same values, a different fix
On 2012-06-15 14:55, Kagamin wrote:
On Friday, 15 June 2012 at 12:17:32 UTC, bearophile wrote:
Even if this version is not documented in Phobos docs (because the
inliner someday will be better), today it allows methods that must be
fast like Nullable.get() to be inlined (but I have not tested th
On 06/15/2012 02:18 PM, Dmitry Olshansky wrote:
On 15.06.2012 16:11, Timon Gehr wrote:
Why not allow equality operators to operate on types?
is(==) expressions tend to create bracket noise and treat the two
arguments non-uniformly.
This would suggest a little parser update, so that eg. 'int',
On 06/15/2012 02:19 PM, bearophile wrote:
Timon Gehr:
Why not allow equality operators to operate on types?
That's nice, of course. But is it possible?
Yes, certainly.
On Friday, 15 June 2012 at 12:17:32 UTC, bearophile wrote:
Even if this version is not documented in Phobos docs (because
the inliner someday will be better), today it allows methods
that must be fast like Nullable.get() to be inlined (but I have
not tested this), regaining the lost performance
On 15.06.2012 16:17, bearophile wrote:
Even if this version is not documented in Phobos docs (because the
inliner someday will be better), today it allows methods that must be
fast like Nullable.get() to be inlined (but I have not tested this),
regaining the lost performance.
If that is sole
On 15.06.2012 16:11, Timon Gehr wrote:
Why not allow equality operators to operate on types?
is(==) expressions tend to create bracket noise and treat the two
arguments non-uniformly.
This would suggest a little parser update, so that eg. 'int', '(int*)'
and 'int[]' are accepted as valid expres
On 15.06.2012 16:17, bearophile wrote:
What do you think about replacing the bailOut() with:
version (halting_enforce)
{
private void bailOut(string file, size_t line, in char[] msg) @safe pure
nothrow
{
assert(0, msg ? msg : "Enforcement failed");
}
}
else
{
private void bailOut(string file,
Timon Gehr:
Why not allow equality operators to operate on types?
That's nice, of course. But is it possible?
Bye,
bearophile
This is the std.typecons.Nullable.get() method:
@property ref inout(T) get() inout pure @safe
{
enforce(!isNull);
return _value;
}
And this is the std.exception.enforce() and bailOut():
T enforce(T, string file = __FILE__, size_t line = __LINE__)
(T value, lazy const(char)[] msg =
Why not allow equality operators to operate on types?
is(==) expressions tend to create bracket noise and treat the two
arguments non-uniformly.
This would suggest a little parser update, so that eg. 'int', '(int*)'
and 'int[]' are accepted as valid expressions. (this also potentially
improves c
On Friday, 15 June 2012 at 06:00:43 UTC, Artur Skawina wrote:
On 06/15/12 00:55, Joseph Rushton Wakeling wrote:
sample = randomSample(iota(0, 100), 5, rndGen);
... should probably be disallowed on grounds of safety.
Considering the output of this program:
import std.stdio;
import s
On Friday, June 15, 2012 10:09:28 Jens Mueller wrote:
> Jonathan M Davis wrote:
> > On Thursday, June 14, 2012 23:37:05 jerro wrote:
> > > Issues with copying rngs are not unique to randomSample - anyone
> > > who uses random number generators will run into them
> > > sooner or later. So the proble
Jonathan M Davis wrote:
> On Thursday, June 14, 2012 23:37:05 jerro wrote:
> > Issues with copying rngs are not unique to randomSample - anyone
> > who uses random number generators will run into them
> > sooner or later. So the problem is not that randomSample takes
> > a rng as a parameter - it's
On Friday, 15 June 2012 at 07:37:14 UTC, Roman D. Boiko wrote:
http://clivetong.wordpress.com/2012/06/15/two-for-the-price-of-one/
The post also mentions monads, so here is another related link:
http://blog.ploeh.dk/2012/05/25/DesignPatternsAcrossParadigms.aspx
:)
http://clivetong.wordpress.com/2012/06/15/two-for-the-price-of-one/
On Friday, 15 June 2012 at 07:15:50 UTC, Jonathan M Davis wrote:
On Friday, June 15, 2012 09:09:48 Don Clugston wrote:
On 10/06/12 23:43, Jonathan M Davis wrote:
> On Sunday, June 10, 2012 23:23:57 Mehrdad wrote:
>> I honestly don't see the POINT of having a "dynamic array
>> literal".
>>
>> Wh
On Friday, June 15, 2012 09:09:48 Don Clugston wrote:
> On 10/06/12 23:43, Jonathan M Davis wrote:
> > On Sunday, June 10, 2012 23:23:57 Mehrdad wrote:
> >> I honestly don't see the POINT of having a "dynamic array
> >> literal".
> >>
> >> What's the point of making the literals dynamic?
> >>
> >
On 10/06/12 23:43, Jonathan M Davis wrote:
On Sunday, June 10, 2012 23:23:57 Mehrdad wrote:
I honestly don't see the POINT of having a "dynamic array
literal".
What's the point of making the literals dynamic?
They should all be static, and only converted to dynamic if
necessary from the contex
On Friday, June 15, 2012 08:58:55 Don Clugston wrote:
> I don't think Phobos should use .di files at all. I don't think there
> are any cases where we want to conceal code.
>
> The performance benefit you would get is completely negligible. It
> doesn't even reduce the number of files that need to
On 14/06/12 10:10, Jonathan M Davis wrote:
On Thursday, June 14, 2012 10:03:05 Don Clugston wrote:
On 13/06/12 16:29, Walter Bright wrote:
On 6/13/2012 1:07 AM, Don Clugston wrote:
On 12/06/12 18:46, Walter Bright wrote:
On 6/12/2012 2:07 AM, timotheecour wrote:
There's a current pull reques
39 matches
Mail list logo
