On 3/30/13, Jonathan M Davis wrote:
> If opCast is defined, it's perfectly
> safe regardless of what would happen if you tried to cast without opCast
> being defined.
Casting is generally unsafe when working with reference types like
classes. For example:
import std.stdio;
final class A
{
B
On Sat, 30 Mar 2013 07:47:56 +0100
Paulo Pinto wrote:
> On 30.03.2013 05:58, Nick Sabalausky wrote:
> > On Fri, 29 Mar 2013 18:45:33 +0100
> > Paulo Pinto wrote:
> >
> >> On 28.03.2013 07:13, js.mdnq wrote:
> >>> I would like to get into writing apps for android and would like
> >>> to choose D
On Saturday, March 30, 2013 08:18:08 Andrej Mitrovic wrote:
> On 3/30/13, Jonathan M Davis wrote:
> > If opCast is defined, it's perfectly
> > safe regardless of what would happen if you tried to cast without opCast
> > being defined.
>
> Casting is generally unsafe when working with reference ty
Examples moved out to unittests:
Cons: doc gets spread out in unittests
Pros: much easier to write those examples, no quoting necessary, code
is syntax highlighted, compilable and ran by unittest suite.
Much better than the hack of embedding examples inside doc
For proof, see how many embedded exam
On 03/30/13 07:12, Jonathan M Davis wrote:
> On Friday, March 29, 2013 22:46:27 Steven Schveighoffer wrote:
>> The issue is when you think you are invoking the opCast operator, but you
>> inadvertently end up casting using the compiler's type-bypassing version.
>> I agree the opCast call is safe, i
On Saturday, March 30, 2013 09:15:24 Artur Skawina wrote:
> On 03/30/13 07:12, Jonathan M Davis wrote:
> > On Friday, March 29, 2013 22:46:27 Steven Schveighoffer wrote:
> >> The issue is when you think you are invoking the opCast operator, but you
> >> inadvertently end up casting using the compil
On 03/30/13 09:22, Jonathan M Davis wrote:
> On Saturday, March 30, 2013 09:15:24 Artur Skawina wrote:
>> On 03/30/13 07:12, Jonathan M Davis wrote:
>>> On Friday, March 29, 2013 22:46:27 Steven Schveighoffer wrote:
The issue is when you think you are invoking the opCast operator, but you
not 'open', there is already something called .expand property
http://forum.dlang.org/thread/fdkalkzhchuerkqlp...@forum.dlang.org
how about this:
auto x = {1,2,3};
auto x2 = {1,2};
assert(x[0..2]==x2);//no expansion
void fun(int x, int y);
fun(x2.expand);
fun(x[0..2].expand);
keeps slicing ortho
this might be relevant: see code that Swig generates when writing C++ wrappers :
eg:
// Support for throwing D exceptions from C/C++.
typedef enum {
SWIG_DException = 0,
SWIG_DIllegalArgumentException,
SWIG_DIllegalElementException,
SWIG_DIOException,
SWIG_DNoSuchElementException,
}
The major downside is that if you don't come from C++ it's hard
to understand why 'ref &' means what you propose. The major
upsides are, as you mention, it's very concise and perfectly
intuitive if you DO come from C++. In the spirit of trying to
come up with something for comparison, the best
I hate this decision, too, but in case you wander, initial
rationale for restricting everything to VM was an attempt to
fight device h/w fragmentization and avoid necessity to build
different application versions for different devices.
Failed attempt, obviously.
Apple have never needed that t
%s/wander/wonder/g
On 30.03.2013 10:43, Dicebot wrote:
I hate this decision, too, but in case you wander, initial rationale for
restricting everything to VM was an attempt to fight device h/w
fragmentization and avoid necessity to build different application
versions for different devices.
Failed attempt, obviousl
I have always wondered how it is done by Win 8. It requires
knowledge of every single released device from Microsoft side,
isn't it? How will it scale?
On Saturday, 30 March 2013 at 09:17:17 UTC, Namespace wrote:
And to pull the reverse: Why should '@val ref' be more
intuitive than ref&? Or why should be '@ref' more intuitive?
What I mean by that:
Both the Property as well as the hybrid path have their
weaknesses and are not necessarily immedi
A few months ago I posted this:
http://forum.dlang.org/thread/mailman.1030.1360125437.22503.digitalmar...@puremagic.com
And this wiki page:
http://wiki.dlang.org/Dispatching_an_object_based_on_its_dynamic_type
But now I've implemented a similar feature for class methods.
Let's say you have a cla
Because & in C++ means "by ref".
D has "ref" for that.
So ref& doesn't make sense. One might think it as a double
reference(?)
You are undermining my authority. :P
I choose ref& because it is a hybrid of the C++ ref style and D's
ref style.
That's what I said in my first post.
And C++ has co
On Saturday, 30 March 2013 at 09:55:27 UTC, Dicebot wrote:
I have always wondered how it is done by Win 8. It requires
knowledge of every single released device from Microsoft side,
isn't it? How will it scale?
Doesn't it only require knowledge of every architecture? And
supporting ARM and x8
Am 30.03.2013 11:12, schrieb Minas Mina:
On Saturday, 30 March 2013 at 09:17:17 UTC, Namespace wrote:
And to pull the reverse: Why should '@val ref' be more intuitive than
ref&? Or why should be '@ref' more intuitive?
What I mean by that:
Both the Property as well as the hybrid path have their w
Personally yes, I prefer @ref more. But you are right that it's
not nice to be an annotation.
I have to agree on that. My first impression was that ref& is
equal to c++11 &&
Kind Regards
Benjamin Thaut
Ok, it seems that I think differently.
And what is the general opinion of '&A' instead of 'ref &A'?
It has all the benefits that I described in my first post, but it
may not be so confu
On 3/30/13, Andrej Mitrovic wrote:
> The full implementation: http://dpaste.dzfl.pl/08278225
Woops! It looks like it may have to become a mixin, since CanCall will
fail to call private methods. So maybe the API would look like:
mixin DynamicDispatch!(C, D, E) dynamic;
As far as I studied the code, something like @ref isn't possible,
because ref is already a keyword. Except as Pseudo-property. But
this is a combination of '@' and 'ref' so that both, '@ref' and
'@ ref' would be valid.
I still like the idea of '&A'.
On 3/30/13, Andrej Mitrovic wrote:
> On 3/30/13, Andrej Mitrovic wrote:
>> The full implementation: http://dpaste.dzfl.pl/08278225
>
> Woops! It looks like it may have to become a mixin, since CanCall will
> fail to call private methods. So maybe the API would look like:
>
> mixin DynamicDispatch
On 2013-03-30 08:26, Nick Sabalausky wrote:
You've got the Go team which has historically been staunchly opposed to
dynamic linking, and the Android team ten miles in the opposite
direction. Classic corporate "left-hand vs right-hand" discrepancy.
Makes them sound like Sony or MS.
That's one t
Am 30.03.2013 12:04, schrieb Namespace:
I have to agree on that. My first impression was that ref& is equal to
c++11 &&
Kind Regards
Benjamin Thaut
Ok, it seems that I think differently.
And what is the general opinion of '&A' instead of 'ref &A'?
It has all the benefits that I described in my
On 2013-03-30 05:06:31 +, "J" said:
Is there anything that would prevent D from catching C++ exceptions?
It would be nice to be able to leverage C++ libraries, but if you can't
catch C++ exceptions, I'm not sure how realistic that is.
That doesn't mean that catch() in D has to be the ca
No I highly appreciate it, that you are trying to solve the
problem. The current state of the language on this is annoying
and it needs to be fixed.
I personally would like &A the question is if this is the
"D-Way". Maybe we should add a new keyword like "vref" for
"value reference".
Kind R
On Sat, 30 Mar 2013 10:53:31 +0100
Paulo Pinto wrote:
> On 30.03.2013 10:43, Dicebot wrote:
> > I hate this decision, too, but in case you wander, initial
> > rationale for restricting everything to VM was an attempt to fight
> > device h/w fragmentization and avoid necessity to build different
>
On Saturday, 30 March 2013 at 13:07:44 UTC, Benjamin Thaut wrote:
Am 30.03.2013 12:04, schrieb Namespace:
I have to agree on that. My first impression was that ref& is
equal to
c++11 &&
Kind Regards
Benjamin Thaut
Ok, it seems that I think differently.
And what is the general opinion of '&A'
On Friday, 29 March 2013 at 12:56:10 UTC, bearophile wrote:
$ is used for array lengths, so it's not so good to overload it
to mean "don't care" too.
Alternative syntaxes:
{c, $_} = tup;
{c, @} = tup;
{c, @_} = tup;
{c, $$} = tup;
{c, {}} = tup;
{c, {_}} = tup;
{c, $~} = tup;
{c, @~= tup;
etc.
Am Fri, 29 Mar 2013 22:39:52 +0100
schrieb "jerro" :
> > Some time ago there was a post on the newsgroup of someone that
> > had a working GDC which would output ARM binaries and he even
> > converted the most important parts of druntime to work for
> > android to. But unfortunately I can't rem
On Friday, 29 March 2013 at 14:03:34 UTC, Steven Schveighoffer
wrote:
Another example, I once had to convert a long type which
represented
Unix time into DateTime. Here's the code to do it:
return
cast(DateTime)SysTime(unixTimeToStdTime(cast(int)d.when.time));
I have three comments here:
1.
Zach the Mystic:
{c, $_} = tup;
{c, @} = tup;
{c, @_} = tup;
{c, $$} = tup;
{c, {}} = tup;
{c, {_}} = tup;
{c, $~} = tup;
{c, @~= tup;
etc.
{c, ?} = tup;
Right, I was forgetting that.
Or this if you want to keep the single "?" for hypothetical
future nullable types:
{c, ?_} = tup;
Bye,
b
There was a discussion about Exceptions in D.learn that may be
relevant.
http://forum.dlang.org/thread/yqzjldpknloyxwlbu...@forum.dlang.org
If you look though the discussion towards the end you'll see
mention of "Lippincott functions", and from there a C++ exception
handler example is shown w
unix time will need a wrapper for strong typing
struct UnixTime { int value; }
SysTime toSysTime(UnixTime fromValue, TimeZone zone=Utc)
{ return SysTime(unixTimeToStdTime(fromValue.value), zone); }
so conversion is
return UnixTime(d.when.time).toTime!DateTime;
may be it can be reduced to
retu
Hello Jacob,
These comments are based on looking into adding Protocol Buffer
as an archive. First some details on the PB format.
https://developers.google.com/protocol-buffers/docs/overview
1) It is a binary format
2) Not all D types can be serialized
3) Serialization is done by message (struc
On 2013-03-30 21:02, Jesse Phillips wrote:
Hello Jacob,
These comments are based on looking into adding Protocol Buffer as an
archive. First some details on the PB format.
https://developers.google.com/protocol-buffers/docs/overview
1) It is a binary format
That shouldn't be a problem. Prefer
On Friday, 29 March 2013 at 19:29:21 UTC, Jonathan M Davis wrote:
because if it
doesn't, you're forced to cast all over the place
There are so many implicit conversions between signed and
unsigned? Are they all ok?
Kagamin:
Jonathan M Davis wrote:
because if it
doesn't, you're forced to cast all over the place
There are so many implicit conversions between signed and
unsigned? Are they all ok?
I think Jonathan doesn't have enough proof that forbidding
signed<->unsigned implicit casts in D is worse t
On Saturday, March 30, 2013 22:12:30 bearophile wrote:
> Kagamin:
> > Jonathan M Davis wrote:
> >> because if it
> >> doesn't, you're forced to cast all over the place
> >
> > There are so many implicit conversions between signed and
> > unsigned? Are they all ok?
>
> I think Jonathan doesn't hav
On Saturday, March 30, 2013 09:53:49 Artur Skawina wrote:
> You can't tell if there is an opCast w/o looking at S. So it's either
> a perfectly fine conversion, no-op, a potentially dangerous operation, or
> an error. The compiler would have been able to catch the error, but by
> overloading 'cast'
Jonathan M Davis:
Walter is the one that you have to convince, and I don't think
that that's ever going to happen.
I understand. But maybe Walter too don't have that proof... I
compile C code with all warnings, and the compiler tells me most
cases of mixing signed with unsigned. I usually re
On 30.03.2013 16:46, Nick Sabalausky wrote:
On Sat, 30 Mar 2013 10:53:31 +0100
Paulo Pinto wrote:
This is how Windows Phone 8 works, by using an offline compiler on
Windows Store to compile .NET to native code, thus you only install
native code, there is no JIT on the devices.
Unless the b
On Sat, 30 Mar 2013 02:06:14 -0400, Jonathan M Davis
wrote:
On Friday, March 29, 2013 22:50:16 Steven Schveighoffer wrote:
On Fri, 29 Mar 2013 19:35:35 -0400, Jonathan M Davis
wrote:
> On Friday, March 29, 2013 10:03:31 Steven Schveighoffer wrote:
>> 1. unixTimeToStdTime should take ulon
On Sat, 30 Mar 2013 17:27:37 -0400, Jonathan M Davis
wrote:
On Saturday, March 30, 2013 09:53:49 Artur Skawina wrote:
You can't tell if there is an opCast w/o looking at S. So it's either
a perfectly fine conversion, no-op, a potentially dangerous operation,
or
an error. The compiler woul
46 matches
Mail list logo
