Hello there, a little late but you might enjoy it. It even
includes an exclusive interview with some of the speakers!
http://blog.sociomantic.com/2013/06/dconf-2013-review/
Feel free to share in all the usual social networks...
On 6/7/13 8:47 AM, Leandro Lucarella wrote:
Hello there, a little late but you might enjoy it. It even includes an
exclusive interview with some of the speakers!
http://blog.sociomantic.com/2013/06/dconf-2013-review/
Feel free to share in all the usual social networks...
Great, I think I'll
Reddit:
http://www.reddit.com/r/programming/comments/1fv4zx/dconf_2013_day_2_talk_6_higgs_an_experimental_jit/
Hackernews: https://news.ycombinator.com/item?id=5839283
Twitter: https://twitter.com/D_Programming/status/343019685744369664
Facebook:
On Friday, 7 June 2013 at 15:05:15 UTC, Andrei Alexandrescu wrote:
Reddit:
http://www.reddit.com/r/programming/comments/1fv4zx/dconf_2013_day_2_talk_6_higgs_an_experimental_jit/
Hackernews: https://news.ycombinator.com/item?id=5839283
Twitter:
On 6/7/13 8:47 AM, Leandro Lucarella wrote:
Hello there, a little late but you might enjoy it. It even includes an
exclusive interview with some of the speakers!
http://blog.sociomantic.com/2013/06/dconf-2013-review/
Feel free to share in all the usual social networks...
I left a bit of time
On Fri, 07 Jun 2013 11:05:14 -0400
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote:
Reddit:
http://www.reddit.com/r/programming/comments/1fv4zx/dconf_2013_day_2_talk_6_higgs_an_experimental_jit/
Hackernews: https://news.ycombinator.com/item?id=5839283
Twitter:
On Fri, 07 Jun 2013 14:47:27 +0200
Leandro Lucarella leandro.lucare...@sociomantic.com wrote:
Hello there, a little late but you might enjoy it. It even
includes an exclusive interview with some of the speakers!
http://blog.sociomantic.com/2013/06/dconf-2013-review/
Feel free to share in
On Thursday, 6 June 2013 at 19:50:51 UTC, Brian Schott wrote:
std.uni was recently accepted for inclusion in Phobos, and as
far as I'm aware there are no reviews currently in progress.
We currently have a backlog of several modules that are ready
for comments or review[1]. There seems to be
On Thursday, 6 June 2013 at 17:32:25 UTC, nazriel wrote:
I am aware that std.process is generalized but I doubt such
useful functionality which is usable on various Posixen is more
disturbing than Windows-only suprpressConsole
On 07/06/13 11:12, Walter Bright wrote:
On 6/6/2013 4:56 PM, Flamaros wrote:
I think it depend of his simplicity and integration in the common D
process
development. Maybe because D build fast we can add some extra steps
during build
of the release?
And developers of companies that develop the
are you talking about http://linux.die.net/man/3/pthread_atfork
funktionality?
Am 06.06.2013 18:05, schrieb nazriel:
Would it be possible to add to std.process.Config POSIX specific
callback which would be called after fork()?
It is currently main blocker in switching dpaste-be from handmade
On 6/6/2013 7:40 PM, Jonathan M Davis wrote:
I've definitely used it before (particularly when originally writing
std.datetime), but it's not something that I remember to use often enough. I'm
thorough enough with my unit tests that I tend to assume that I have fully
coverage (which I probably
On 6/6/2013 9:34 PM, Brad Roberts wrote:
On 6/6/13 6:12 PM, Walter Bright wrote:
and I'm the only one I know of that uses it.
You really need to get out of the habit of associating I can't remember people
telling me they use something and no one uses it.
1) your memory isn't perfect.
On 6/6/2013 11:30 PM, Peter Williams wrote:
I use it to make sure that my unittests are complete.
Awesome!
-cov is also useful for:
1. debugging - if your unittests can't seem to cover certain lines, those lines
might indicate a bug
2. performance - giving usage counts of lines tells you
On 6/6/2013 10:04 PM, Andrei Alexandrescu wrote:
I'm carefully mentioning entire applications every time I got a chance. It's
not working.
As Jonathan mentioned, I don't see how this can work with shared libraries
(especially dynamically loaded ones), as you cannot know what the entire
On Thursday, 6 June 2013 at 20:50:08 UTC, David Nadlinger wrote:
On Wednesday, 5 June 2013 at 20:49:19 UTC, Walter Bright wrote:
uses C printf (!) in the examples,
Again, trying to make it lightweight.
… and wrong, in more than one way.
David
(What happens if the input is larger than
On 6/6/2013 10:14 PM, Andrei Alexandrescu wrote:
I don't buy all that humans aren't rational stuff.
I don't either, but I don't think that was my point.
My point is that a language where -O delivers the performance is preferable to a
language that you have to do careful annotations and run
On Friday, 7 June 2013 at 05:59:24 UTC, Lars T. Kyllingstad wrote:
On Thursday, 6 June 2013 at 17:32:25 UTC, nazriel wrote:
I am aware that std.process is generalized but I doubt such
useful functionality which is usable on various Posixen is
more disturbing than Windows-only suprpressConsole
On Friday, 7 June 2013 at 07:57:07 UTC, nazriel wrote:
Again, I am not forcing anything on you or Steven.
I am asking you for opinion on something I find useful because
you are the experts and I really like your work on new
std.process
It's not up to us either. If the community wants it,
Am 07.06.2013 10:21, schrieb Lars T. Kyllingstad:
On Friday, 7 June 2013 at 07:57:07 UTC, nazriel wrote:
Again, I am not forcing anything on you or Steven.
I am asking you for opinion on something I find useful because
you are the experts and I really like your work on new
std.process
It's
On Thu, 06 Jun 2013 22:59:41 +0200, Sad panda sunsp...@gmail.com wrote:
Can we use some other word for counterargument than destroy please. :(
(resume discussion)
But we like destroy.
--
Simen
On Friday, 7 June 2013 at 06:27:32 UTC, dennis luehring wrote:
are you talking about http://linux.die.net/man/3/pthread_atfork
funktionality?
Very interesting. That may be exactly what I need.
I will try this out and see how does it play with std.process.
Thanks a lot!
On Friday, 7 June 2013 at 08:21:32 UTC, Lars T. Kyllingstad wrote:
On Friday, 7 June 2013 at 07:57:07 UTC, nazriel wrote:
Again, I am not forcing anything on you or Steven.
I am asking you for opinion on something I find useful because
you are the experts and I really like your work on new
On Thursday, 6 June 2013 at 18:10:11 UTC, Jonathan M Davis wrote:
If you have that problem, then you don't publicly import the
entire module.
It's up to the package designer to decide which portions of the
package get
publicly imported. But since std.datetime.Foo would be
ambiguous, I don't
On 06/07/2013 09:22 AM, Walter Bright wrote:
...
There are two obvious reasons why a feature would not have much buzz:
1. it works perfectly
2. it isn't being used
Value Range Propagation is a pretty good example of (1). Sadly, I
suspect -cov is (2).
I'd be happy to be wrong about that.
On Friday, 7 June 2013 at 07:42:58 UTC, Walter Bright wrote:
My point is that a language where -O delivers the performance
is preferable to a language that you have to do careful
annotations and run extra tools on to get it.
Depends on target audience. Some want tight control over
resulting
On Wednesday, 5 June 2013 at 13:19:33 UTC, Peter Lundgren wrote:
The problem I'm trying to solve (and maybe this isn't as
important as I think) is that DMocks or deject + DMocks only
works on a subset of the language. I can't mock out free
function calls, private or final methods, or functions
On Fri, 07 Jun 2013 07:20:12 +0200, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 6/7/13 12:34 AM, Brad Roberts wrote:
On 6/6/13 6:12 PM, Walter Bright wrote:
and I'm the only one I know of that uses it.
You really need to get out of the habit of associating I can't
On Friday, 7 June 2013 at 07:22:18 UTC, Walter Bright wrote:
A pretty good metric of some feature being used is the
frequency it comes up in discussion here and the action it sees
in bugzilla.
There are two obvious reasons why a feature would not have much
buzz:
1. it works perfectly
2. it
On Friday, 7 June 2013 at 10:35:12 UTC, Peter Alexander wrote:
Or it just isn't used much compared to other things and works
well enough when it is.
For what it's worth, there are a few bugs on Bugzilla about
-cov, so it is being used.
It is also worth saying that -cov is more of production
On 6/7/13, nazriel s...@dzfl.pl wrote:
But still it looks weird to me that allowing access to
std.datetime.time.Clock via std.datetime.Clock, even though Clock
is defined in std.datetime.time and std.datetime.package is only
publicly importing it, is ok.
This could come as a benefit. For
W dniu 07.06.2013 07:28, Tyler Jameson Little pisze:
This would make D the truely universal language it was intended to be.
I'd love to see that! I think that Phobos code that makes allocations
can be divided (duplicated) to manual and GC versions.
I thought I read somewhere about a marker
On 06/06/2013 07:10 PM, Rob T wrote:
My understanding is that final on it's own would be an error if the same named
function was virtual in the base class, otherwise you would have to specify
final override. If that understanding is not correct, then I agree that
would
be a source of hidden
On Friday, 7 June 2013 at 07:42:15 UTC, Peter Alexander wrote:
On Thursday, 6 June 2013 at 20:50:08 UTC, David Nadlinger wrote:
On Wednesday, 5 June 2013 at 20:49:19 UTC, Walter Bright wrote:
uses C printf (!) in the examples,
Again, trying to make it lightweight.
… and wrong, in more than
This code fails to compile because T is deduced to be `const int`:
void foo(T)(T x)
{
x++;
}
void main()
{
const int y = 0;
foo(y);
}
Analogous code in C++ works because C++ strips the top-level
const.
Is there any reason this isn't done in D with non-ref value type
On Friday, 7 June 2013 at 13:47:59 UTC, David Nadlinger wrote:
On Friday, 7 June 2013 at 07:42:15 UTC, Peter Alexander wrote:
On Thursday, 6 June 2013 at 20:50:08 UTC, David Nadlinger
wrote:
On Wednesday, 5 June 2013 at 20:49:19 UTC, Walter Bright
wrote:
uses C printf (!) in the examples,
On Thu, 06 Jun 2013 15:54:24 +0100, Dylan Knutson tcdknut...@gmail.com
wrote:
On Thursday, 6 June 2013 at 10:48:54 UTC, Lars T. Kyllingstad wrote:
On Thursday, 6 June 2013 at 10:32:36 UTC, Regan Heath wrote:
On Thu, 06 Jun 2013 08:55:50 +0100, Lars T. Kyllingstad
pub...@kyllingen.net
If the nogc marker could be used to overload functions then
Phobos may include both versions of the code - GC and non GC -
as some code may run faster under GC. The calling function
would pick up the right one.
I can't imagine how this would work without over-complicating the
syntax. Any
On Fri, 07 Jun 2013 16:39:15 +0200, Tyler Jameson Little
beatgam...@gmail.com wrote:
If the nogc marker could be used to overload functions then Phobos may
include both versions of the code - GC and non GC - as some code may
run faster under GC. The calling function would pick up the right
On Friday, 7 June 2013 at 14:46:30 UTC, Simen Kjaeraas wrote:
On Fri, 07 Jun 2013 16:39:15 +0200, Tyler Jameson Little
beatgam...@gmail.com wrote:
If the nogc marker could be used to overload functions then
Phobos may include both versions of the code - GC and non GC
- as some code may run
W dniu 07.06.2013 17:01, Tyler Jameson Little pisze:
On Friday, 7 June 2013 at 14:46:30 UTC, Simen Kjaeraas wrote:
On Fri, 07 Jun 2013 16:39:15 +0200, Tyler Jameson Little
beatgam...@gmail.com wrote:
If the nogc marker could be used to overload functions then Phobos
may include both versions
On Fri, 07 Jun 2013 17:01:27 +0200, Tyler Jameson Little
beatgam...@gmail.com wrote:
@nogc void foo() {} // #1
@safe void foo() {} // #2
@nogc void baz() {
foo();
}
Which gets called when -safe is passed?
I'm not familiar with -safe, but in the example above #1 would be
On Friday, 7 June 2013 at 07:31:52 UTC, Walter Bright wrote:
deadalnix mentioned enforcing 'export' on classes exposed to
shared libraries, but then aren't we back to expecting user
annotation rather than doing things automatically?
Yes, let me explain more.
The export problem isn't new, and
On 6/7/13 3:42 AM, Walter Bright wrote:
On 6/6/2013 10:14 PM, Andrei Alexandrescu wrote:
I don't buy all that humans aren't rational stuff.
I don't either, but I don't think that was my point.
My point is that a language where -O delivers the performance is
preferable to a language that you
On Friday, 7 June 2013 at 13:58:33 UTC, Peter Alexander wrote:
This code fails to compile because T is deduced to be `const
int`:
void foo(T)(T x)
{
x++;
}
void main()
{
const int y = 0;
foo(y);
}
Analogous code in C++ works because C++ strips the top-level
const.
Is there
On Friday, 7 June 2013 at 16:24:16 UTC, monarch_dodra wrote:
I seem to specifically remember that it *didn't* work this way.
Isn't this a regression?
...and I seem to have been wrong. This has never worked.
And I can also confirm that C++ does strip the top level const in
this case.
I
On Friday, 7 June 2013 at 16:24:16 UTC, monarch_dodra wrote:
I seem to specifically remember that it *didn't* work this way.
Isn't this a regression?
I checked the last 5 versions, and this code has never compiled.
(If it were a regression, I would have hoped a unit test would
have caught
On Friday, 7 June 2013 at 16:33:50 UTC, monarch_dodra wrote:
On Friday, 7 June 2013 at 16:24:16 UTC, monarch_dodra wrote:
I seem to specifically remember that it *didn't* work this
way. Isn't this a regression?
...and I seem to have been wrong. This has never worked.
And I can also confirm
On Friday, 7 June 2013 at 07:22:18 UTC, Walter Bright wrote:
A pretty good metric of some feature being used is the
frequency it comes up in discussion here and the action it sees
in bugzilla.
There are two obvious reasons why a feature would not have much
buzz:
1. it works perfectly
2.
On Thursday, 6 June 2013 at 19:29:08 UTC, Jonathan M Davis wrote:
On Thursday, June 06, 2013 14:38:41 Andrei Alexandrescu wrote:
On 6/6/13 2:13 PM, Jonathan M Davis wrote:
An example of a strong justification for a redo is, for
example,
conversion
to use ranges. std.zip needs that
On 6/7/13 1:04 PM, monarch_dodra wrote:
I think using string as the main form of representation for a path is fine.
However, there are times where it is convenient to be able to explode a
path into a structure, where each part is clearly separate from the
next.
Tuple!(
string, drive,
On Friday, 7 June 2013 at 17:27:16 UTC, Andrei Alexandrescu wrote:
On 6/7/13 1:04 PM, monarch_dodra wrote:
I think using string as the main form of representation for a
path is fine.
However, there are times where it is convenient to be able to
explode a
path into a structure, where each
On 6/7/13 2:10 PM, monarch_dodra wrote:
On Friday, 7 June 2013 at 17:27:16 UTC, Andrei Alexandrescu wrote:
On 6/7/13 1:04 PM, monarch_dodra wrote:
I think using string as the main form of representation for a path is
fine.
However, there are times where it is convenient to be able to explode
On Friday, 7 June 2013 at 18:26:42 UTC, Andrei Alexandrescu wrote:
On 6/7/13 2:10 PM, monarch_dodra wrote:
On Friday, 7 June 2013 at 17:27:16 UTC, Andrei Alexandrescu
wrote:
On 6/7/13 1:04 PM, monarch_dodra wrote:
I think using string as the main form of representation for
a path is
fine.
On 6/6/13 1:02 PM, Michel Fortin wrote:
and Apple has Case-sensitive HFS+ for OS X and its the default on iOS.
Careful.. While HFS+ can be case sensitive, it's not by default. Nor is it recommended due to the
number of osx applications that just aren't designed with that in mind.
Hi guys,
This is a small feature proposal.
Please consider to add these to the language:
cast(signed)
cast(unsigned)
Motivation:
- To remove the need to write cast(ulong) x and repeat the
underlying type, which is the same motivation as cast(const),
cast(immutable), cast(shared)
On 6/7/13 4:52 PM, Mrzlga wrote:
Hi guys,
This is a small feature proposal.
Please consider to add these to the language:
cast(signed)
cast(unsigned)
http://dlang.org/phobos/std_traits.html#.unsigned
We should prolly add signed() as well. Could you please author an
enhancement request (and
On Friday, 7 June 2013 at 20:52:53 UTC, Mrzlga wrote:
That's it!
Thanks for your consideration :)
FWI, you can use std.trait's Signed and Unsigned as a partial
alternative.
http://dlang.org/phobos/std_traits.html#.Signed
IMO, not quite as elegant. I support this syntax. It's natural,
and
On Friday, 7 June 2013 at 20:52:53 UTC, Mrzlga wrote:
- Use the library for it and instead make signed(x),
unsigned(x) templates.
I think this is a really strong counterargument and one I'd like
to see done, along with other kinds of casts in the library.
Downsides to this solution:
On Friday, 7 June 2013 at 21:04:40 UTC, monarch_dodra wrote:
On Friday, 7 June 2013 at 20:52:53 UTC, Mrzlga wrote:
That's it!
Thanks for your consideration :)
FWI, you can use std.trait's Signed and Unsigned as a partial
alternative.
http://dlang.org/phobos/std_traits.html#.Signed
IMO,
On Friday, June 07, 2013 10:55:36 nazriel wrote:
If it was carefully discussed and I somehow missed those
discussion or I am not allowed to see them, then I am sorry and
please ignore this and my previous post in this topic.
Actually, Daniel Murphy, Martin Nowak, and I discussed it with Walter
A reason for cast(signed) is to discourage the user from writing:
cast(int) x;
Because we can't grep for the word signed,
We have to search for cast( ) only!
cast(int) x// hides the intention, hard to search for!
Yet we can easily grep for:
cast(signed)
On Friday, 7 June 2013 at 21:34:00 UTC, Mrzlga wrote:
A reason for cast(signed) is to discourage the user from
writing:
cast(int) x;
Because we can't grep for the word signed,
We have to search for cast( ) only!
cast(int) x// hides the intention, hard to search for!
Yet we can
Andrei, what do you think about the unsigned(x) not showing up on
greps for 'cast'? No problem? Is the grep irrelevant? Not all
casts should be marked as a cast?
People told me the grepping was important, so I tried to work
their idea in.
I understand, you can still search for:
signed(
On Friday, 7 June 2013 at 22:05:46 UTC, Idan Arye wrote:
but not as good as the template solution
Should be not as good as the syntactic sugar solution
On Friday, 7 June 2013 at 21:42:05 UTC, Jesse Phillips wrote:
On Friday, 7 June 2013 at 21:34:00 UTC, Mrzlga wrote:
A reason for cast(signed) is to discourage the user from
writing:
cast(int) x;
Because we can't grep for the word signed,
We have to search for cast( ) only!
cast(int) x
On Thursday, 6 June 2013 at 19:50:51 UTC, Brian Schott wrote:
std.uni was recently accepted for inclusion in Phobos, and as
far as I'm aware there are no reviews currently in progress.
We currently have a backlog of several modules that are ready
for comments or review[1]. There seems to be
On 6/7/2013 2:52 AM, Timon Gehr wrote:
You are certainly wrong about the value range propagation part. The transformers
for the bitwise operators are not the best possible.
ubyte x = ((y252)^2)+1;
The above term can be easily proven to fit into ubyte by just using an analysis
of the ranges of
On Thursday, 6 June 2013 at 18:31:08 UTC, Walter Bright wrote:
Ok, Manu, you win, I'm pretty much convinced.
So what does this mean? We got 'virtual' with the next release? :)
On Friday, 7 June 2013 at 22:41:56 UTC, Brad Anderson wrote:
On Thursday, 6 June 2013 at 19:50:51 UTC, Brian Schott wrote:
std.uni was recently accepted for inclusion in Phobos, and as
far as I'm aware there are no reviews currently in progress.
We currently have a backlog of several modules
On 6/7/2013 9:51 AM, Rob T wrote:
If D had a compiler option switch to collect statistics on feature usage, maybe
you could get something a lot better than a guess for both 1 and 2.
And then you'd have to convince people to use it and send you the results!
So from my dconf talk, I detailed a nasty hack to handle member function
pointers in D.
My approach is not portable, so I'd like to see an expression formalised in
D, so this sort of interaction with C++ is possible, and also it may be
useful in D code directly.
I'm thinking something like
On 2013-06-07 20:52:30 +, Brad Roberts bra...@puremagic.com said:
On 6/6/13 1:02 PM, Michel Fortin wrote:
and Apple has Case-sensitive HFS+ for OS X and its the default on iOS.
Careful.. While HFS+ can be case sensitive, it's not by default. Nor
is it recommended due to the number of
On Friday, 7 June 2013 at 23:22:03 UTC, Manu wrote:
Currently, to get the instance or function pointers from a
delegate, you need to do something like:
delegates have two members, ptr and funcptr:
http://dlang.org/function.html
As a fun fact, if you modify druntime's allocator to be malloc(),
On 2013-06-07 23:21:53 +, Manu turkey...@gmail.com said:
Thoughts?
Reminds me of something similar I implemented a while ago:
http://michelf.ca/projects/d-objc/syntax/#selector-literals
Not only I think member function pointers are doable, but I think
they're solely missing. There have
On 8 June 2013 09:42, Adam D. Ruppe destructiona...@gmail.com wrote:
On Friday, 7 June 2013 at 23:22:03 UTC, Manu wrote:
Currently, to get the instance or function pointers from a delegate, you
need to do something like:
delegates have two members, ptr and funcptr:
On 6/7/2013 8:23 AM, deadalnix wrote:
Yes, let me explain more.
Thanks for the detailed explanation.
On 8 June 2013 09:48, Michel Fortin michel.for...@michelf.ca wrote:
On 2013-06-07 23:21:53 +, Manu turkey...@gmail.com said:
Thoughts?
Reminds me of something similar I implemented a while ago:
On 6/7/13 5:41 PM, Mrzlga wrote:
Andrei, what do you think about the unsigned(x) not showing up on greps
for 'cast'? No problem? Is the grep irrelevant? Not all casts should be
marked as a cast?
People told me the grepping was important, so I tried to work their idea
in.
I understand, you can
On Friday, 7 June 2013 at 23:52:59 UTC, Walter Bright wrote:
On 6/7/2013 8:23 AM, deadalnix wrote:
Yes, let me explain more.
Thanks for the detailed explanation.
If you are looking further material on the topic, you might also
want to try a quick web search for '-fvisibility=hidden', which
On Thursday, 6 June 2013 at 19:50:51 UTC, Brian Schott wrote:
std.uni was recently accepted for inclusion in Phobos, and as
far as I'm aware there are no reviews currently in progress.
We currently have a backlog of several modules that are ready
for comments or review[1]. There seems to be
On 8 June 2013 01:23, deadalnix deadal...@gmail.com wrote:
Requiring classes to be exported provide the following benefit :
- LTO can finalize methods that aren't overridden. It include function
that you want virtual by design, but you don't use that capability is your
specific situation. In
On Friday, 7 June 2013 at 23:54:55 UTC, Manu wrote:
The properties are already there...
but they're not properly typed.
I just don't think they can be unless we change the visible type
which isn't always what we want but, check this out:
// this new type keeps track of the exact type of
How about this: if `Foo` is a template with a single type
parameter that returns a type, writing `cast(Foo)bar` will be
parsed as `cast(Foo!(typeof(bar))bar`.
My proposal has a bad thing about it:
The 'unsigned' and 'signed' keywords can't be as easily extended
the way that an signed(x)
On 07/06/13 17:28, Walter Bright wrote:
On 6/6/2013 11:30 PM, Peter Williams wrote:
I use it to make sure that my unittests are complete.
Awesome!
-cov is also useful for:
1. debugging - if your unittests can't seem to cover certain lines,
those lines might indicate a bug
That's what I
doing nothing but converting unsigned-signed is a dubious
statement.
They are still screwing with the range, they are not just doing
nothing but converting unsigned-signed.
And 'int' says something about the outcome.
So I am really asking for:
cast(signed int) x; // make them poor
On 8 June 2013 10:24, Adam D. Ruppe destructiona...@gmail.com wrote:
On Friday, 7 June 2013 at 23:54:55 UTC, Manu wrote:
The properties are already there...
but they're not properly typed.
I just don't think they can be unless we change the visible type which
isn't always what we want
I'm against it since we can do it better in library with same efficiency
and better UFCS syntax: see
https://github.com/timotheecour/dtools/blob/master/dtools/util/cast_funs.d
to test it, nothing to install, just type: rdmd --main -unittest
dtools/all.d
here's the unittest:
On Saturday, 8 June 2013 at 01:11:46 UTC, Manu wrote:
I initially started with something like this. But look how much
code it is!
Yeah...
You've basically wrapped up a delegate, and made something that
emulates a delegate
(I'm not sure why?).
I just wanted to add type safety to a
On Friday, 7 June 2013 at 22:57:01 UTC, Walter Bright wrote:
On 6/7/2013 9:51 AM, Rob T wrote:
If D had a compiler option switch to collect statistics on
feature usage, maybe
you could get something a lot better than a guess for both 1
and 2.
And then you'd have to convince people to use it
On Saturday, 8 June 2013 at 00:43:28 UTC, Mrzlga wrote:
doing nothing but converting unsigned-signed is a dubious
statement.
They are still screwing with the range, they are not just
doing nothing but converting unsigned-signed.
And 'int' says something about the outcome.
So I am really
Timothy,
How do you get everyone to use:
a.Cast!Signed
a.Cast!Unsigned
a.Cast!Const
a.Cast!Immutable
a.Cast!Shared
And to stop using:
cast(const)
cast(immutable)
cast(shared)
cast(inout) ?
And have everyone be consistent about it?
Remove the cast() ones
So, you want a syntactic salt that will force people to write
No, no, I don't actually want the salt. I hoped I had indicated
that in my message.
It was only for your consideration about cast(int), how it would
be nice to indicate everything if there was no price to it.
On Fri, Jun 7, 2013 at 6:53 PM, Mrzlga bulletproofch...@gmail.com wrote:
Timothy,
How do you get everyone to use:
a.Cast!Signed
a.Cast!Unsigned
a.Cast!Const
a.Cast!Immutable
a.Cast!Shared
And to stop using:
cast(const)
cast(immutable)
cast(shared)
What is the -safe option? I don't see it in DMD help.
@safe is specified without @nogc, but calling function is
@nogc, so I think that #1 should be chosen.
I pulled that from here: http://dlang.org/memory-safe-d.html
Maybe that's out of date?
On Friday, June 07, 2013 18:43:11 Peter Alexander wrote:
Ack, it appears it is only done for arrays and pointers :-S
And it pretty much only does that because of all of the issues that const and
immutable strings were giving us with range-based functions. IFTI now
automatically slices arrays,
I don't know the story of how D resolved to not provide 'ulong'
and 'unsigned long' as equivalent, but I do understand the
motivation to keep things short and standard, with
1-word-per-basic-type.
I should say one thing though,
In C / C++:
unsigned x = f(); // this was traumatic. unsigned
not to mention its much harder to implement in language, whereas its
trivial in the library. Also, it makes instrumentation easier, if one wants
to add a callback/logging/breakpoint for a particular cast operation. Seems
much harder with language solution.
On Fri, Jun 7, 2013 at 6:53 PM, Mrzlga
On Saturday, 8 June 2013 at 02:21:01 UTC, Timothee Cour wrote:
not to mention its much harder to implement in language,
whereas its
trivial in the library. Also, it makes instrumentation easier,
if one wants
to add a callback/logging/breakpoint for a particular cast
operation. Seems
much
not suggesting deprecating cast(), just suggesting there's no
need to
extend the language as it can be done in library code,
advantageously. It's
trivially extensible as I wrote it. However, any language
extension has to
be re-implemented by each compiler implementation.
I don't think you
1 - 100 of 191 matches
Mail list logo
