On Thursday, 28 March 2024 at 01:53:52 UTC, Steven Schveighoffer
wrote:
```d
class Base {}
class Derived : Base {}
@safe pure nothrow unittest {
Base b;
Derived d;
b = d; // pass
Base[] bs;
Derived[] ds;
bs ~= ds; // pass
bs = ds; // fail
On Monday, 25 March 2024 at 07:16:35 UTC, Per Nordlöw wrote:
On Saturday, 23 March 2024 at 11:04:04 UTC, Dmitry Olshansky
wrote:
The first and second is unsound (infamously allowed in Java).
In the general case, yes. But, do you see any errors with the
code
```d
class Base {}
class Derived
On Saturday, 23 March 2024 at 11:04:04 UTC, Dmitry Olshansky
wrote:
The first and second is unsound (infamously allowed in Java).
In the general case, yes. But, do you see any errors with the code
```d
class Base {}
class Derived : Base {}
@safe pure nothrow unittest {
Base b;
On Saturday, 23 March 2024 at 11:04:04 UTC, Dmitry Olshansky
wrote:
On Saturday, 23 March 2024 at 09:08:45 UTC, Per Nordlöw wrote:
Is there a reason why
```d
class Base {}
class Derived : Base {}
@safe pure nothrow unittest {
Base b;
Derived d;
b = d; // pass
On Saturday, 23 March 2024 at 09:08:45 UTC, Per Nordlöw wrote:
Is there a reason why
```d
class Base {}
class Derived : Base {}
@safe pure nothrow unittest {
Base b;
Derived d;
b = d; // pass
Base[] bs;
Derived[] ds;
bs ~= ds; // pass
bs
Is there a reason why
```d
class Base {}
class Derived : Base {}
@safe pure nothrow unittest {
Base b;
Derived d;
b = d; // pass
Base[] bs;
Derived[] ds;
bs ~= ds; // pass
bs = ds; // fail [1], should pass
bs = cast(Base[])ds; //
On Saturday, March 23, 2024 12:11:15 AM MDT Per Nordlöw via Digitalmars-d-
learn wrote:
> Why doesn't string implicitly convert to immutable(ubyte)[] in
> @safe mode?
Why would it? They're different types. Their elements happen to have the
same size, but that doesn't mean that they're used for
On Wednesday, 24 January 2024 at 09:28:57 UTC, Renato wrote:
If you have "widespread" arithmetics which may overflow,
something like https://dlang.org/phobos/core_checkedint.html is
useful, yes, but in this case it's overkill.
To make use of this, one needs to already anticipate an
On Wednesday, 24 January 2024 at 00:34:19 UTC, bachmeier wrote:
On Tuesday, 23 January 2024 at 21:40:46 UTC, Renato wrote:
While I can understand your frustration, it seems to me D is
not to blame in this instance because the code is quite
patently using unsafe constructs (D does not claim to
On Tuesday, 23 January 2024 at 23:40:55 UTC, Danilo wrote:
How did you make it correct?
Write 2 different versions for `signed` and `unsigned` types?
Or could you utilize `core.checkedint` somehow for checking
overflow?
```d
double value(T)(T index, double * x) {
bool overflow;
On Tuesday, 23 January 2024 at 23:40:55 UTC, Danilo wrote:
On Tuesday, 23 January 2024 at 17:54:25 UTC, bachmeier wrote:
Here's a reduced version of one of the most bizarre bugs I've
dealt with in any language. The only reason I didn't move on
to another language was because I was too busy at
On Tuesday, 23 January 2024 at 21:40:46 UTC, Renato wrote:
While I can understand your frustration, it seems to me D is
not to blame in this instance because the code is quite
patently using unsafe constructs (D does not claim to be fully
safe).
It pretends to be safe. Consider this:
```
On Tuesday, 23 January 2024 at 17:54:25 UTC, bachmeier wrote:
Here's a reduced version of one of the most bizarre bugs I've
dealt with in any language. The only reason I didn't move on to
another language was because I was too busy at the time.
The code allows for initial values if the index
On Tuesday, 23 January 2024 at 21:40:46 UTC, Renato wrote:
While I can understand your frustration, it seems to me D is
not to blame in this instance because the code is quite
patently using unsafe constructs
I wouldn't blame bachmeier, because many reduced testcases
distilled from the real
On Tuesday, 23 January 2024 at 21:18:53 UTC, bachmeier wrote:
There are two things things that cause the problem. One is the
use of a template and the other is passing an unsigned type.
The reason the first parameter uses a template is because there
are a lot of types I could send as the first
On Tuesday, 23 January 2024 at 19:27:26 UTC, Renato wrote:
Here's a reduced version of one of the most bizarre bugs I've
dealt with in any language. The only reason I didn't move on
to another language was because I was too busy at the time.
The code allows for initial values if the index is
On Tuesday, 23 January 2024 at 17:54:25 UTC, bachmeier wrote:
On Tuesday, 23 January 2024 at 12:34:38 UTC, Nick Treleaven
wrote:
But I'm strongly in favour of catching any bugs at
compile-time (and have been since before I discovered D). I
just object to anyone trying to downgrade the
On Tuesday, 23 January 2024 at 12:34:38 UTC, Nick Treleaven wrote:
But I'm strongly in favour of catching any bugs at compile-time
(and have been since before I discovered D). I just object to
anyone trying to downgrade the importance of automated
memory-safety checking.
I'm not downgrading
On Monday, 22 January 2024 at 19:49:19 UTC, Siarhei Siamashka
wrote:
The two's complement wraparound behavior mandated by the D
language spec is a non-technical political decision, intended
to make life easier for the DMD compiler developers, but
ignoring the needs of the users.
Actually it
On Monday, 22 January 2024 at 19:11:50 UTC, Siarhei Siamashka
wrote:
On Monday, 22 January 2024 at 16:39:10 UTC, Nick Treleaven
wrote:
Memory safety issues are a worse class of bug than arithmetic
bugs. The latter are reproducible if you feed them the same
input.
Memory safety bugs are
On Monday, 22 January 2024 at 17:15:55 UTC, bachmeier wrote:
I get incorrect results, and when I'm lucky, my program
segfaults because I accessed something I shouldn't. When I'm
not, it silently and happily gives me the wrong answer.
Maybe a compiler warning (not error) would help with
On Monday, 22 January 2024 at 01:14:06 UTC, Steven Schveighoffer
wrote:
On Sunday, 21 January 2024 at 16:05:40 UTC, Gavin Gray wrote:
The following code:
ulong charlie = 11;
long johnstone = std.algorithm.comparison.max(0, -charlie);
writeln(format!"johnstone %s"(johnstone));
Results in
On Monday, 22 January 2024 at 16:39:10 UTC, Nick Treleaven wrote:
Memory safety issues are a worse class of bug than arithmetic
bugs. The latter are reproducible if you feed them the same
input.
Memory safety bugs are reproducible with the tools like
`valgrind`. Whereas arithmetic overflow
On Monday, 22 January 2024 at 16:39:10 UTC, Nick Treleaven wrote:
I've said multiple times that it's silly to spend so much time
on memory safety if the language is going to allow stuff like
this without a simple way to prevent it.
Memory safety issues are a worse class of bug than
the bigger issue is implicit conversion from unsigned to
signed of the same bit size. In a future edition D could require
a larger signed type in order to implicitly convert from
unsigned. That would have caught the `long johnstone =` line.
Also signed should never convert to unsigned, though I
r had stopped and provided an
error message to tell them what they were doing. Note that in
this line
```
long johnstone = std.algorithm.comparison.max(0, -charlie);
```
there is no direct assignment of a negative number to an unsigned
type. The comparison is carried out as ulong and then there's
On Sunday, 21 January 2024 at 16:05:40 UTC, Gavin Gray wrote:
The following code:
ulong charlie = 11;
long johnstone = std.algorithm.comparison.max(0, -charlie);
writeln(format!"johnstone %s"(johnstone));
Results in (without any warning(s)):
johnstone -11
However you choose to look at
Gavin Gray via Digitalmars-d-learn wrote:
The following code:
ulong charlie = 11;
long johnstone = std.algorithm.comparison.max(0, -charlie);
writeln(format!"johnstone %s"(johnstone));
Results in (without any warning(s)):
johnstone -11
However you choose to look at it, this means -11
On Monday, 22 January 2024 at 01:14:06 UTC, Steven Schveighoffer
wrote:
On Sunday, 21 January 2024 at 16:05:40 UTC, Gavin Gray wrote:
The following code:
ulong charlie = 11;
long johnstone = std.algorithm.comparison.max(0, -charlie);
writeln(format!"johnstone %s"(johnstone));
Results in
On Sunday, 21 January 2024 at 16:05:40 UTC, Gavin Gray wrote:
The following code:
ulong charlie = 11;
long johnstone = std.algorithm.comparison.max(0, -charlie);
writeln(format!"johnstone %s"(johnstone));
Results in (without any warning(s)):
johnstone -11
However you choose to look at
The following code:
ulong charlie = 11;
long johnstone = std.algorithm.comparison.max(0, -charlie);
writeln(format!"johnstone %s"(johnstone));
Results in (without any warning(s)):
johnstone -11
However you choose to look at it, this means -11 > 0 (regardless
of all arguments concerning
On Tuesday, 23 March 2021 at 01:07:15 UTC, Steven Schveighoffer
wrote:
And the answer is complex. You can't accept a const range,
because they don't work. The only way to have purity infer
uniqueness is to accept paramters that the result could not
have come from. Usually this means accepting
On Tuesday, 23 March 2021 at 01:07:15 UTC, Steven Schveighoffer
wrote:
const(char)[] x = "foo";
string chained = chainPath(x, "bar").array;
that calls the template overload
ForeachType!Range[] array(Range)(Range r)
if (isIterable!Range && !isAutodecodableString!Range &&
!isInfinite!Range)
On 23.03.21 02:07, Steven Schveighoffer wrote:
const(char)[] x = "foo";
string chained = chainPath(x, "bar").array;
Error: cannot implicitly convert expression array(chainPath(x, "bar"))
of type const(char)[] to string
And the answer is complex. You can't accept a const range, because they
On 3/22/21 5:58 PM, ag0aep6g wrote:
On 22.03.21 21:38, Per Nordlöw wrote:
Am I the only one being annoyed by the fact that
chainPath(...).array
doesn't implicit convert to string despite the array returned from
.array is allocated by the GC.
Works for me:
import std.array:
On 22.03.21 21:38, Per Nordlöw wrote:
Am I the only one being annoyed by the fact that
chainPath(...).array
doesn't implicit convert to string despite the array returned from
.array is allocated by the GC.
Works for me:
import std.array: array;
import std.path: chainPath;
void
On Monday, 22 March 2021 at 20:38:36 UTC, Per Nordlöw wrote:
chainPath(...).array
To clarify, for instance, given
string s;
const(char)[] c;
all the calls
chainPath(s, s).array
chainPath(c, c).array
chainPath(s, c).array
chainPath(c, s).array
return
Am I the only one being annoyed by the fact that
chainPath(...).array
doesn't implicit convert to string despite the array returned
from .array is allocated by the GC.
Yes, I know that I should do
chainPath(...).array.assumeUnique
but the uniqueness of .array (and in turn implicit
On Tuesday, 10 November 2020 at 11:49:19 UTC, Jerry wrote:
On Tuesday, 10 November 2020 at 11:38:30 UTC, Vladimirs
Nordholm wrote:
Hello.
I am unsure if I am going about this the right way, and if my
question even makes sense.
In essence what I want is to have two "types" represented by a
On Tuesday, 10 November 2020 at 11:38:30 UTC, Vladimirs Nordholm
wrote:
Hello.
I am unsure if I am going about this the right way, and if my
question even makes sense.
In essence what I want is to have two "types" represented by a
size_t. Here is an example of what I want think I want (but
Hello.
I am unsure if I am going about this the right way, and if my
question even makes sense.
In essence what I want is to have two "types" represented by a
size_t. Here is an example of what I want think I want (but might
be completely off)
alias Foo = size_t;
alias Bar =
On Fri, Nov 06, 2020 at 03:36:46PM +, Paul Backus via Digitalmars-d-learn
wrote:
[...]
> User-defined implicit conversions are one of the most error-prone
> features of C++, and have been deliberately excluded from D, with the
> exception of `alias this`.
And Walter is already expressing
== S1)) { return
S1(); } }
nor suitable ctor
struct S1 { this(const S2 s){} }
are used for implicit conversion?
This is impossible by design. User-defined implicit conversions
are one of the most error-prone features of C++, and have been
deliberately excluded from D, with the exception of `alias this`.
On Monday, 9 March 2020 at 16:44:55 UTC, Steven Schveighoffer
wrote:
You're not the first person to ask.
Accepted.
On 3/9/20 11:35 AM, Manfred Nowak wrote:
Having a function `f' overloaded for argument types `bool' and `ulong',
the specs guarantee, that for `f( 1uL)' the boolean overload of `f' is
called.
What is this good for?
You're not the first person to ask.
Having a function `f' overloaded for argument types `bool' and
`ulong', the specs guarantee, that for `f( 1uL)' the boolean
overload of `f' is called.
What is this good for?
ction, but regardless,
it's just a different syntax for calling the constructor. The only way to
create an implicit conversion with a user-defined type in D is to use alias
this, and that only provides a way to implicitly convert _from_ a
user-defined type, not to a type. So, having
Num funk()
{
return
On Wednesday, 8 August 2018 at 08:44:03 UTC, Alex wrote:
return typeof(return)(5);
Ah thanks, I was wondering if something like that exists. Still
though, that's 16 extra characters that dont need to be there.
On Wednesday, 8 August 2018 at 08:15:16 UTC, Hakan Aras wrote:
Given this:
struct Num
{
this(int a) {}
}
Is there any reason why this works:
Num n = 5;
but this doesnt:
Num funk()
{
return 5;
}
I understand that I can construct it explicitely, but that gets
annoying quickly,
Given this:
struct Num
{
this(int a) {}
}
Is there any reason why this works:
Num n = 5;
but this doesnt:
Num funk()
{
return 5;
}
I understand that I can construct it explicitely, but that gets
annoying quickly, especially with templates.
On Thursday, 19 July 2018 at 06:35:36 UTC, Simen Kjærås wrote:
On Wednesday, 18 July 2018 at 11:28:54 UTC, Timoses wrote:
But why is a context pointer a problem? Is it problematic
because the context pointer to the main scope can not
guarantee `immutable`? E.g. if I happened to use data from
On Wednesday, 18 July 2018 at 11:28:54 UTC, Timoses wrote:
But why is a context pointer a problem? Is it problematic
because the context pointer to the main scope can not guarantee
`immutable`? E.g. if I happened to use data from main in a
function of the immutable struct then... well then
On Tuesday, 17 July 2018 at 06:24:12 UTC, Simen Kjærås wrote:
That makes sense. The problem is F has a context pointer to the
main() block, since it's a non-static struct with methods
inside a block. It doesn't actually use the context pointer for
anything, so it possibly shouldn't have one,
On Monday, 16 July 2018 at 13:13:53 UTC, Timoses wrote:
On Monday, 16 July 2018 at 12:00:57 UTC, Simen Kjærås wrote:
On Monday, 16 July 2018 at 11:43:03 UTC, Timoses wrote:
Why does this fail?
It doesn't. Not using DMD 2.081.1 under Windows, at least. I
tried adding a bitfield since you
On Monday, 16 July 2018 at 13:13:53 UTC, Timoses wrote:
On Monday, 16 July 2018 at 12:00:57 UTC, Simen Kjærås wrote:
On Monday, 16 July 2018 at 11:43:03 UTC, Timoses wrote:
Why does this fail?
It doesn't. Not using DMD 2.081.1 under Windows, at least. I
tried adding a bitfield since you
On Monday, 16 July 2018 at 12:00:57 UTC, Simen Kjærås wrote:
On Monday, 16 July 2018 at 11:43:03 UTC, Timoses wrote:
Why does this fail?
It doesn't. Not using DMD 2.081.1 under Windows, at least. I
tried adding a bitfield since you mentioned it, but it compiles
nicely for me. Which version
On Monday, 16 July 2018 at 11:43:03 UTC, Timoses wrote:
Why does this fail?
It doesn't. Not using DMD 2.081.1 under Windows, at least. I
tried adding a bitfield since you mentioned it, but it compiles
nicely for me. Which version of DMD are you using, and are you
having the issues with the
Why does this fail?
struct F
{
int i;
ushort _x;
void x(ushort v) pure
{_x = v;}
ushort x() const
{ return _x; }
}
immutable F f1 = () pure {
F lf = F();
return lf; }();
// Error: cannot implicitly convert expression
;
int toInt()
{
return x;
}
use fromInt(int v)
{
return use(v);
}
alias toInt this; // implicit conversion to int value
this(int v)
{x = v;}
}
void useP(int v)
{
v.writeln;
}
void useV(T)(T v
nt(int v)
> {
> return use(v);
> }
>
> alias toInt this; // implicit conversion to int value
>
> this(int v)
> {x = v;}
> }
>
> void useP(int v)
> {
> v.writeln;
> }
>
> void useV(use v)
> {
> v.writeln;
> }
>
&g
Hello,
I want to convert from ints implicit to a struct type, so for
example:
struct use
{
int x;
int toInt()
{
return x;
}
use fromInt(int v)
{
return use(v);
}
alias toInt this; // implicit
On 8/17/17 5:28 PM, Balagopal Komarath wrote:
On Thursday, 17 August 2017 at 20:22:09 UTC, Steven Schveighoffer wrote:
This should "work". I don't think your static assert will pass, but
the main function below should run.
Thanks. But, isn't my static assert testing for exactly this?
I
On Thursday, 17 August 2017 at 20:22:09 UTC, Steven Schveighoffer
wrote:
This should "work". I don't think your static assert will pass,
but the main function below should run.
Thanks. But, isn't my static assert testing for exactly this?
On 8/17/17 3:24 PM, Balagopal Komarath wrote:
Is it possible to make structs containing slices support implicit
conversion from const to mutable?
This should "work". I don't think your static assert will pass, but the
main function below should run.
struct A
{
int[] a;
A d
Is it possible to make structs containing slices support implicit
conversion from const to mutable? I tried adding a postblit that
dupes the member 'a'. That didn't work.
struct A
{
int[] a;
}
void main()
{
static assert (is(const(A) : A)); // fails
}
On Sunday, 21 May 2017 at 10:03:58 UTC, Nicholas Wilson wrote:
As in the function signature of the function you call `ok` or
`error` in.
Result!(int, SomeEnum) myfunc(bool foo)
{
if(!foo)
return ok(42);
else
return error(SomeEnum.fooHappened);
}
should work.
This is
On Sunday, 21 May 2017 at 09:55:41 UTC, David Zhang wrote:
On Sunday, 21 May 2017 at 09:37:46 UTC, Nicholas Wilson wrote:
On Sunday, 21 May 2017 at 09:29:40 UTC, David Zhang wrote:
Well then it becomes
Result!(T, E) ok(T,E) (T t) { return Result(t); }
Result!(T, E) error(T,E)(E e) {
On Sunday, 21 May 2017 at 09:37:46 UTC, Nicholas Wilson wrote:
On Sunday, 21 May 2017 at 09:29:40 UTC, David Zhang wrote:
Well then it becomes
Result!(T, E) ok(T,E) (T t) { return Result(t); }
Result!(T, E) error(T,E)(E e) { return Result(e); }
and then provided it can be inferred (e.g.
On Sunday, 21 May 2017 at 09:29:40 UTC, David Zhang wrote:
On Sunday, 21 May 2017 at 09:15:56 UTC, Nicholas Wilson wrote:
have free functions
Result!(T, ErrorEnum) ok(T)(T t) { return Result(t); }
Result!(T, ErrorEnum) error(T)(ErrorEnum e) { return
Result(e); }
then go
if (!foo)
On Sunday, 21 May 2017 at 09:15:56 UTC, Nicholas Wilson wrote:
have free functions
Result!(T, ErrorEnum) ok(T)(T t) { return Result(t); }
Result!(T, ErrorEnum) error(T)(ErrorEnum e) { return
Result(e); }
then go
if (!foo)
return ok(42);
else
return error(Error.fooHappened);
Ah,
On Sunday, 21 May 2017 at 08:44:31 UTC, David Zhang wrote:
Hi,
I was reading a bit about this in Rust, and their enum type. I
was wondering if this is replicate-able in D. What I've got
right now is rather clunky, and involves using
`typeof(return).ok` and `typeof(return).error)`.
Hi,
I was reading a bit about this in Rust, and their enum type. I
was wondering if this is replicate-able in D. What I've got right
now is rather clunky, and involves using
`typeof(return).ok` and `typeof(return).error)`.
While that's not too bad, it does involve a lot more typing,
On Tuesday, 7 June 2016 at 22:28:57 UTC, Steven Schveighoffer
wrote:
It's news to me that while opCast for all other types is for
explicit
casting, opCast for bool works for implicit casting.
as ag0... mentioned in another thread, opCast is NOT implicitly
being invoked here, but rather
On 6/7/16 6:15 PM, Ali Çehreli wrote:
On 06/06/2016 08:28 AM, Adam D. Ruppe wrote:
On Monday, 6 June 2016 at 15:23:50 UTC, chmike wrote:
I would like an implicit conversion of Info to bool that return false
if category_ is null so that I can write
add:
bool opCast(T : bool)() {
return
On 06/06/2016 08:28 AM, Adam D. Ruppe wrote:
On Monday, 6 June 2016 at 15:23:50 UTC, chmike wrote:
I would like an implicit conversion of Info to bool that return false
if category_ is null so that I can write
add:
bool opCast(T : bool)() {
return whatever;
}
to the struct and it should
On Monday, 6 June 2016 at 15:34:18 UTC, chmike wrote:
On Monday, 6 June 2016 at 15:28:35 UTC, John wrote:
Thank you John and Adam. That was a quick answer !
Too late but another option would have been to put an alias this
on a bool getter:
struct Info
{
bool getStuff()
{
On Monday, 6 June 2016 at 15:28:35 UTC, John wrote:
Thank you John and Adam. That was a quick answer !
On Monday, 6 June 2016 at 15:23:50 UTC, chmike wrote:
I would like an implicit conversion of Info to bool that return
false if category_ is null so that I can write
add:
bool opCast(T : bool)() {
return whatever;
}
to the struct and it should work.
.
T opCast(T : bool)() {
return category_ !is null;
}
...
private:
Category category_ = null;
int value_ = 0;
}
I would like an implicit conversion of Info to bool that return
false if category_ is null so that I can write
Info s = foo();
if (s
On Friday, June 03, 2016 16:12:50 maik klein via Digitalmars-d-learn wrote:
> Any ideas?
Well, alias this is the only way that D supports any kind of implicit
conversions for user-defined types. So, if you want to have an implicit
conversion for your type, you're going to have to figure out
implicit conversion with alias this from Ok!T to
Result!(T, ???) because "Ok" doesn't know about the error type.
That is a bit unergonomic because I always seem to need the full
type
like
auto ok(T, E)(auto ref T value){
return Result!(T, E)(Ok!T(value));
}
I basically try
On 02/14/2016 03:43 PM, Tofu Ninja wrote:
So I wrote a simple ref counted string type because using the built in
strings without the GC is extremely painful. It there any way I can get
strings to implicitly convert to my custom string type?
No, D does not support such implicit conversions.
So I wrote a simple ref counted string type because using the
built in strings without the GC is extremely painful. It there
any way I can get strings to implicitly convert to my custom
string type?
Some way to make this work...
struct rstring {...}
void fun(rstring s) {...}
...
fun("hello
On 11/06/2015 04:56 PM, BBaz wrote:
On Thursday, 5 November 2015 at 13:20:26 UTC, ixid wrote:
This may have been overlooked in my other thread so I wanted to ask
again:
This seems very inconsistent, does a += b not lower to a = a + b? I
guess not based on the below:
ushort a = ushort.max,
On Thursday, 5 November 2015 at 13:20:26 UTC, ixid wrote:
This may have been overlooked in my other thread so I wanted to
ask again:
This seems very inconsistent, does a += b not lower to a = a +
b? I guess not based on the below:
ushort a = ushort.max, b = ushort.max;
a += b; //
On Saturday, 7 November 2015 at 01:10:01 UTC, Ali Çehreli wrote:
On 11/06/2015 04:56 PM, BBaz wrote:
On Thursday, 5 November 2015 at 13:20:26 UTC, ixid wrote:
[...]
What's inconsistent is the integral promotion of the add
expression
result that stops from 4 bytes int:
---
int a, b;
a +=
On Thursday, 5 November 2015 at 09:33:40 UTC, ixid wrote:
In C++ I can add two shorts together without having to use a
cast to assign the result to one of the two shorts. It just
seems super clunky not to be able to do basic operations on
basic types without casts everywhere.
+1
If
ote:
>> Is there an elegant way of avoiding implicit conversion to
>> int when you're using shorter types?
>
> Only with library solution. Implicit conversions are built
> into language.
Doesn't that seem rather limiting and unnecessary?
Why? You can't affect what conversions do and don't work
And I want to have small number litterals automatically choosing
the smallest fitting type.
If I write
ubyte b = 1u;
auto c = b + 1u;
I expect the 1u to be of type ubyte - and also c.
On 11/05/2015 05:20 AM, ixid wrote:
> This seems very inconsistent, does a += b not lower to a = a + b?
Apparently not:
http://dlang.org/expression.html#AssignExpression
It says "The right operand is implicitly converted to the type of the
left operand". So, the rules are different.
Ali
On Thursday, 5 November 2015 at 13:23:34 UTC, Adam D. Ruppe wrote:
On Thursday, 5 November 2015 at 10:07:30 UTC, Dominikus Dittes
Scherkl wrote:
ubyte b = 1u;
auto c = b + 1u;
I expect the 1u to be of type ubyte - and also c.
This won't work because of the one-expression rule. In the
On Thursday, 5 November 2015 at 22:15:46 UTC, Dominikus Dittes
Scherkl wrote:
On Thursday, 5 November 2015 at 13:23:34 UTC, Adam D. Ruppe
wrote:
On Thursday, 5 November 2015 at 10:07:30 UTC, Dominikus Dittes
Scherkl wrote:
ubyte d = b + (ubyte)1;
Sorry, should of course be:
ubyte d = b +
On Thursday, November 05, 2015 09:33:39 ixid via Digitalmars-d-learn wrote:
> In C++ I can add two shorts together without having to use a cast
> to assign the result to one of the two shorts. It just seems
> super clunky not to be able to do basic operations on basic types
> without casts
This may have been overlooked in my other thread so I wanted to
ask again:
This seems very inconsistent, does a += b not lower to a = a + b?
I guess not based on the below:
ushort a = ushort.max, b = ushort.max;
a += b; // Compiles fine
a = a + b; // Error: cannot implicitly
On Thursday, 5 November 2015 at 10:07:30 UTC, Dominikus Dittes
Scherkl wrote:
And I want to have small number litterals automatically
choosing the smallest fitting type.
It does, that's the value range propagation at work. Inside one
expression, if the compiler can prove it fits in a smaller
On Wednesday, 4 November 2015 at 19:09:42 UTC, Maxim Fomin wrote:
On Wednesday, 4 November 2015 at 14:27:49 UTC, ixid wrote:
Is there an elegant way of avoiding implicit conversion to int
when you're using shorter types?
Only with library solution. Implicit conversions are built
On Wednesday, 4 November 2015 at 21:22:04 UTC, ixid wrote:
On Wednesday, 4 November 2015 at 19:09:42 UTC, Maxim Fomin
wrote:
On Wednesday, 4 November 2015 at 14:27:49 UTC, ixid wrote:
Is there an elegant way of avoiding implicit conversion to
int when you're using shorter types?
Only
On Wednesday, November 04, 2015 21:22:02 ixid via Digitalmars-d-learn wrote:
> On Wednesday, 4 November 2015 at 19:09:42 UTC, Maxim Fomin wrote:
> > On Wednesday, 4 November 2015 at 14:27:49 UTC, ixid wrote:
> >> Is there an elegant way of avoiding implicit conversion to int
>
On Wednesday, 4 November 2015 at 14:27:49 UTC, ixid wrote:
Is there an elegant way of avoiding implicit conversion to int
when you're using shorter types?
Only with library solution. Implicit conversions are built into
language.
On Wednesday, 4 November 2015 at 14:27:49 UTC, ixid wrote:
Is there an elegant way of avoiding implicit conversion to int
when you're using shorter types?
Also does this not seem inconsistent:
ushort a = ushort.max, b = ushort.max;
a += b; // Compiles fine
a = a + b; // Error
1 - 100 of 198 matches
Mail list logo
