On 4/3/2014 9:54 PM, Meta wrote:
In the case of your example, alias this does not make
it typesafe, as a MyInt can still be implicitly converted to int.
You can disable the implicit conversion to int with this scheme. The alias this
only takes effect if there is no other member that will take
On Fri, Apr 4, 2014 at 9:05 AM, Walter Bright newshou...@digitalmars.comwrote:
You can disable the implicit conversion to int with this scheme. The alias
this only takes effect if there is no other member that will take the
operation.
What is the exact method of disabling the implicit cast?
On Thursday, 3 April 2014 at 01:55:48 UTC, Andrei Alexandrescu
wrote:
A lot of them could apply to us as well.
https://www.youtube.com/watch?v=TS1lpKBMkgg
Andrei
He's got a point in mentioning things like def equals(x: Any):
Boolean and def compare(x: T, y: T): Int (although the latter
is
On Thursday, 3 April 2014 at 22:58:24 UTC, w0rp wrote:
I notice that he mentioned the objection to defining equality
and so on for the root object. I have heard this before from
Philip Wadler, and the more I think about it, the more it makes
sense. This is essentially the idea of removing
On Friday, 4 April 2014 at 07:43:18 UTC, Bienlein wrote:
On Thursday, 3 April 2014 at 01:55:48 UTC, Andrei Alexandrescu
wrote:
A lot of them could apply to us as well.
https://www.youtube.com/watch?v=TS1lpKBMkgg
Andrei
He's got a point in mentioning things like def equals(x: Any):
Boolean
On Friday, 4 April 2014 at 07:43:18 UTC, Bienlein wrote:
On Thursday, 3 April 2014 at 01:55:48 UTC, Andrei Alexandrescu
wrote:
A lot of them could apply to us as well.
https://www.youtube.com/watch?v=TS1lpKBMkgg
Andrei
He's got a point in mentioning things like def equals(x: Any):
Boolean
On Friday, 4 April 2014 at 08:00:09 UTC, w0rp wrote:
I think this is a really interesting argument. Don't write ugly
things to get performance. Instead write obviously correct
things and then make obvious optimisations.
Bah, except that if you use everywhere big ints, floating point
On Friday, 4 April 2014 at 08:05:58 UTC, renoX wrote:
On Friday, 4 April 2014 at 08:00:09 UTC, w0rp wrote:
I think this is a really interesting argument. Don't write
ugly things to get performance. Instead write obviously
correct things and then make obvious optimisations.
Bah, except that
On Friday, 4 April 2014 at 02:38:58 UTC, Andrei Alexandrescu
wrote:
On 4/3/14, 7:04 AM, Don wrote:
https://www.sociomantic.com/dunnhumby-acquires-sociomantic/
Congratulations to all involved!
How will this impact the use of D at dunnhumby?
Andrei
This is going to be very big for D. Our
On Friday, 4 April 2014 at 08:16:20 UTC, Paulo Pinto wrote:
Says who? And slow to whom?
1 - Write correct code
2 - Use a profiler, if the code isn't fast enough for the use
case being written for
3 - If desired use case isn't there, use the profiler
information to improve the specific
On 4/4/2014 12:23 AM, Rory McGuire wrote:
On Fri, Apr 4, 2014 at 9:05 AM, Walter Bright newshou...@digitalmars.com
mailto:newshou...@digitalmars.com wrote:
You can disable the implicit conversion to int with this scheme. The alias
this only takes effect if there is no other member that
On Friday, 4 April 2014 at 09:07:31 UTC, Dicebot wrote:
On Friday, 4 April 2014 at 08:16:20 UTC, Paulo Pinto wrote:
Says who? And slow to whom?
1 - Write correct code
2 - Use a profiler, if the code isn't fast enough for the use
case being written for
3 - If desired use case isn't there,
okay, awesome, I guessed correctly then. (on where to find it anyway).
On Fri, Apr 4, 2014 at 11:16 AM, Walter Bright
newshou...@digitalmars.comwrote:
On 4/4/2014 12:23 AM, Rory McGuire wrote:
On Fri, Apr 4, 2014 at 9:05 AM, Walter Bright newshou...@digitalmars.com
Walter Bright:
Because every cast breaks the type system. A type system that
requires too many casts for normal things is NOT a type safe
system.
I have explained this on numerous occasions.
You have discussed many times about the unsafety of casts and I
agree with your point of view. I
I suspect that in my D code most cast usage does not need casts
if you replace them with stronger casts as the enum class of
C++11, but I have no proof of this.
Too much casting. I meant to say:
I suspect that in my D code most usages of enum don't need casts
if you replace them with
On Friday, 4 April 2014 at 07:43:22 UTC, Paulo Pinto wrote:
Java came up with it most likely as it was the way in Smalltalk.
That's right. As Smalltalk is dynamically typed it is not an
issue there anyway and Java to begin with had to parameterized
types till JDK4.
I guess you need to be
04-Apr-2014 13:16, Walter Bright пишет:
On 4/4/2014 12:23 AM, Rory McGuire wrote:
On Fri, Apr 4, 2014 at 9:05 AM, Walter Bright newshou...@digitalmars.com
mailto:newshou...@digitalmars.com wrote:
You can disable the implicit conversion to int with this scheme.
The alias
this only takes
First use alias this go import functionality transparently. Then use
opImplicitCast to set what can be implicitly casted to.
On 04 Apr 2014 12:45 PM, Dmitry Olshansky dmitry.o...@gmail.com wrote:
04-Apr-2014 13:16, Walter Bright пишет:
On 4/4/2014 12:23 AM, Rory McGuire wrote:
On Fri, Apr 4,
On Friday, 4 April 2014 at 09:16:26 UTC, Walter Bright wrote:
It's supposed to be by adding your own opImplicitCast overload,
but that isn't implemented yet.
Wait, this is back? What else did the community get wrong when
trying to interpret discussions?
On Monday, 31 March 2014 at 21:41:26 UTC, Théo Bueno wrote:
Mono-D seems pretty complete to me now, I was wondering if you
are thinking about new major features ?
http://mono-d.alexanderbothe.com/mono-d-v1-9-opindexopslice-overload-recognition-completion/
:-)
On Fri, 04 Apr 2014 07:35:18 -0700, Alexander Bothe
i...@alexanderbothe.com wrote:
On Monday, 31 March 2014 at 21:41:26 UTC, Théo Bueno wrote:
Mono-D seems pretty complete to me now, I was wondering if you are
thinking about new major features ?
On Fri, 04 Apr 2014 10:21:28 -0700, Adam Wilson flybo...@gmail.com wrote:
On Fri, 04 Apr 2014 07:35:18 -0700, Alexander Bothe
i...@alexanderbothe.com wrote:
On Monday, 31 March 2014 at 21:41:26 UTC, Théo Bueno wrote:
Mono-D seems pretty complete to me now, I was wondering if you are
On Fri, 04 Apr 2014 07:35:18 -0700, Alexander Bothe
i...@alexanderbothe.com wrote:
On Monday, 31 March 2014 at 21:41:26 UTC, Théo Bueno wrote:
Mono-D seems pretty complete to me now, I was wondering if you are
thinking about new major features ?
On 4/4/2014 3:24 AM, bearophile wrote:
You see I care of casts also from the little casts statistic I've done on your
Warp:
http://forum.dlang.org/thread/lhf0u6$2r80$1...@digitalmars.com?page=3#post-wjjivmmeyeismgkntwsj:40forum.dlang.org
Most of the casts in Warp come from the workarounds I
On Friday, 4 April 2014 at 18:02:02 UTC, Walter Bright wrote:
Here's one:
enum Index { A, B, C }
T[Index.max] array; // Error: Index.max is not an int
...
array[B] = t; // Error: B is not an int
And another:
array[A + 1] = t; // Error: incompatible types Index and int
And
On Friday, 4 April 2014 at 18:15:43 UTC, Meta wrote:
And another:
array[A + 1] = t; // Error: incompatible types Index and int
And another:
enum Mask { A=1,B=4 }
Mask m = A | B; // Error: incompatible operator | for enum
and on it goes. These are routine and normal uses of enums.
Walter Bright:
Thank you for the answers.
Here's one:
enum Index { A, B, C }
T[Index.max] array; // Error: Index.max is not an int
...
array[B] = t; // Error: B is not an int
In the last months I've grown a moderate desire for optionally
strongly typed array indexes in D (as seen
On Friday, 4 April 2014 at 17:32:52 UTC, Adam Wilson wrote:
I think I have a syntax highlighting regression. The following
code from module core.sys.windows.windows used to be
highlighted when used in my own modules in 1.7.3 but is now
regular black text:
alias LONG HRESULT;
Well,
Meta:
Also, if I remember correctly, min and max are terribly
broken for enums in the first place.
Yes, perhaps they need to be deprecated.
Also, there is a ugly name clashing between enum field names and
the enum properties. The solution is to group them into a single
namespace (like
And another:
enum Mask { A=1,B=4 }
Mask m = A | B; // Error: incompatible operator | for enum
That would be a 'set of enum' in Pascal/Delphi.
On Fri, Apr 04, 2014 at 11:02:01 -0700, Walter Bright wrote:
Most of the casts in Warp come from the workarounds I had to do to
get around the auto-decode of std.array.front(). I have designed
byChar, byWchar and byDchar ranges for Phobos to get around this
issue, but that is stalled now
array[Succ!(Index.A)] = t;
auto i = Index.A;
array[i.succ] = t;
And with enum precondition in the succ() function you can do
both cases with a single function:
array[Index.A.succ] = t;
auto i = Index.A;
array[i.succ] = t;
Bye,
bearophile
On Fri, 04 Apr 2014 11:44:44 -0700, Alexander Bothe
i...@alexanderbothe.com wrote:
On Friday, 4 April 2014 at 17:32:52 UTC, Adam Wilson wrote:
I think I have a syntax highlighting regression. The following code
from module core.sys.windows.windows used to be highlighted when used
in my
On Friday, 4 April 2014 at 19:20:18 UTC, Adam Wilson wrote:
If possible it would be nice for aliases to be highlighted per
their underlying type, so struct aliases highlight differently
than primitive aliases? It would be an interesting way to
provide semantic information to the user about
On 4/4/2014 11:47 AM, bearophile wrote:
Also, there is a ugly name clashing between enum field names and the enum
properties. The solution is to group them into a single namespace (like meta),
and then forbid an enum member with the name of the namespace.
On 4/4/2014 12:05 PM, bearophile wrote:
And with enum precondition in the succ() function you can do both cases with a
single function:
array[Index.A.succ] = t;
auto i = Index.A;
array[i.succ] = t;
What about i+10? Do you expect the person to write
On Friday, 4 April 2014 at 18:57:44 UTC, Ben Boeckel wrote:
On Fri, Apr 04, 2014 at 11:02:01 -0700, Walter Bright wrote:
Most of the casts in Warp come from the workarounds I had to
do to
get around the auto-decode of std.array.front(). I have
designed
byChar, byWchar and byDchar ranges for
On 2014-04-04 04:31, Walter Bright wrote:
On 4/3/2014 7:19 PM, bearophile wrote:
I have asked for fully typesafe enums in D,
You can do this:
struct MyInt {
int x;
alias this x;
... put your various constraints here ...
}
to get typesafe enums. In fact, you
38 matches
Mail list logo
