Re: char[] == null

[Maxim Fomin via Digitalmars-d-learn]

On Thursday, 19 November 2015 at 15:36:44 UTC, Steven 
Schveighoffer wrote:
On 11/19/15 3:30 AM, Jonathan M Davis via Digitalmars-d-learn 
wrote:
On Wednesday, November 18, 2015 22:15:19 anonymous via 
Digitalmars-d-learn wrote:

On 18.11.2015 22:02, rsw0x wrote:

slices aren't arrays
http://dlang.org/d-array-article.html


The language reference/specification [1] uses the term 
"dynamic array"
for T[] types. Let's not enforce a slang that's different 
from that.



[1] http://dlang.org/arrays.html


Exactly. T[] _is_ a dynamic array. Steven's otherwise 
wonderful article on
arrays in D ( http://dlang.org/d-array-article.html ) made the 
mistake of
calling the buffer that T[] points to on the GC heap (assuming 
that even
does point to the GC heap) the dynamic array. And per the 
language spec,

that's not true at all.


It was not a mistake :) It's how I still think of it. The spec 
is confusing, and my terminology, IMO, is a much more 
consistent (and accurate) way to think of it.


-Steve


Why formal definition of dynamic array caused confusion and is 
inconsistent? It is well consistent with static array and other 
aggregate types notions.


Consider this:

int *x = new int; // this is 'int type' ans it is 'dynamic'
int y;
int *a = // and this is not 'int type'

The problem is treating chunk of heap memory as some kind of type 
(dynamic in this case). Type of object determines an interface of 
interacting with object while storage determines memory location 
and possibly duration of lifetime. It is possible to have object 
of any type to be allocated on different storages - for example, 
slice does not necessarily points to dynamic array (in your 
terms). C and C++ established a long tradition of such standard 
notions as object, lifetime, storage and type. From system 
language perspective calling memory a type (in other words, type 
of object depends on where it was allocated) does not make much 
sense.

Re: Preventing implicit conversion

[Maxim Fomin via Digitalmars-d-learn]

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 with library solution. Implicit conversions are built 
into language.


Doesn't that seem rather limiting and unnecessary?


Well, indeed it often produces confusion (this is inherited from 
C for compatibility purpose).

Re: Preventing implicit conversion

[Maxim Fomin via Digitalmars-d-learn]

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.

Re: Overloading an imported function

[Maxim Fomin via Digitalmars-d-learn]

On Wednesday, 21 October 2015 at 12:05:27 UTC, Shriramana Sharma 
wrote:

import std.math;
real round(real val, int prec)
{
real pow = 10 ^^ prec;
return round(val * pow) / pow;
}

Trying to compile this I get:

foo.d(5): Error: function foo.round (real val, int prec) is not 
callable using argument types (real)


When I've imported std.math which contains round(real), why is 
the compiler complaining about not being able to call the 
overload function defined in *this* module?


I don't see anything in http://dlang.org/module.html that says 
I cannot define an overload of an imported function. Did I miss 
something?


My guess is that .round shadows math.round. But you can 
get desired behavior
by moving declaration of math.round inside scope of 
.round. This compiles:


real round(real val, int prec)
{
import std.math;
real pow = 10 ^^ prec;
return round(val * pow) / pow;
}

Re: Array of subclasses

[Maxim Fomin via Digitalmars-d-learn]

On Thursday, 22 October 2015 at 13:29:06 UTC, DarkRiDDeR wrote:


I don't need the base class data. How to create a array of 
subclasses objects with the derived data members?


The language is implemented in this way. You have already have 
the answer:



writeln(Core.users.name)
Out:
USERS

Re: Array of subclasses

[Maxim Fomin via Digitalmars-d-learn]

On Thursday, 22 October 2015 at 11:02:05 UTC, DarkRiDDeR wrote:


This variant works strangely. Example:

abstract class Addon
{
public string name = "0";
}
class Users: Addon
{
override
{
public string name = "USERS";
}
}
static final class Core
{
static:
public Addon[] activated;
public Users users;

public void activate()
{
users = new Users;
activated = [new Users, new Users];
}
}

Core.activate();
writeln(Core.users.name ~ "\n"  ~ Core.activated[1].name);

Out:
USERS
0


First of all, the code does not compile with override. It is 
impossible to override a data. Override should be removed.
The reason it works this way is that the first access is to base 
class data while the second is to the derived data member.

Re: Implicit conversion rules

[Maxim Fomin via Digitalmars-d-learn]

On Wednesday, 21 October 2015 at 19:49:35 UTC, Ali Çehreli wrote:

On 10/21/2015 12:37 PM, Sigg wrote:

> cause at least few more "fun" side effects.

One of those side effects would be function calls binding 
silently to another overload:


void foo(bool){/* ... */}
void foo(int) {/* ... */}

  auto a = 0;  // If the type were deduced by the value,
  foo(a);  // then this would be a call to foo(bool)...
   // until someone changed the value to 2. :)

Ali


Actually 'a' is deduced to be int, so int version is called (as 
expected?). See my example above for the VRO overload issue.

Re: Implicit conversion rules

[Maxim Fomin via Digitalmars-d-learn]

On Wednesday, 21 October 2015 at 22:49:16 UTC, Marco Leise wrote:

Am Wed, 21 Oct 2015 12:49:35 -0700
schrieb Ali Çehreli :


On 10/21/2015 12:37 PM, Sigg wrote:

 > cause at least few more "fun" side effects.

One of those side effects would be function calls binding 
silently to another overload:


void foo(bool){/* ... */}
void foo(int) {/* ... */}

   auto a = 0;  // If the type were deduced by the value,
   foo(a);  // then this would be a call to foo(bool)...
// until someone changed the value to 2. :)

Ali


God forbid anyone implement such nonsense into D !
That would be the last thing we need that we cannot rely on
the overload resolution any more. It would be as if making 'a'
const would change the overload resolution when none of the
overloads deal with constness...



AFAIK it was implemented long time ago and discussed last time 
couple of years ago with example similar to Ali's.


void foo(bool)
void foo(int)

foo(0); // bool
foo(1); // bool
foo(2); // int

Re: how come is this legal? 'void fun(int){ }' ?

[Maxim Fomin via Digitalmars-d-learn]

On Sunday, 14 June 2015 at 01:20:39 UTC, Timothee Cour wrote:
I understand this is legal for declaration wo definition (void 
fun(int);)

but why allow this:
void test(int){} ?


Actually it is void test(int _param_0) { }
You can test by compiling void test(int) { _param_0 = 0; }

Nameless parameters are simulated by providing internal symbol as 
above.

Re: Cannot Qualify Variadic Functions with Lazy Arguments as nothrow

[Maxim Fomin via Digitalmars-d-learn]

On Thursday, 14 May 2015 at 09:53:20 UTC, Per Nordlöw wrote:

At

https://github.com/nordlow/justd/blob/master/algorithm_ex.d#L43

I've implemented a function either() with behaviour similar to 
the `or` function/operator in dynamic languages such as Python 
and Lisp.


I'm almost satisified with it except that the lazy evaluation at

https://github.com/nordlow/justd/blob/master/algorithm_ex.d#L45

cannot be made nothrow.

If I qualify the function as nothrow DMD complains as

algorithm_ex.d(45,16): Error: 'a' is not nothrow
algorithm_ex.d(46,29): Error: '_param_1' is not nothrow

I don't see a reason why any of these two cases should throw.


Lazy argument is essentially delegate/function. Currently there 
is no

way to mark it as nothrow.

The same problem occurs if I make the implementation use only 
one function and check the recursion termination case with 
`static if (bs.length == 1)` instead.


Is there a workaround for this?


One way to address is to use delegate explicitly.

int foo(lazy int a) //nothrow
{
return a;
}

int bar(int delegate() nothrow dg) nothrow
{
return dg();
}

void main() nothrow
{
int a;
bar(()=a);
}

Re: Can't modify this

[Maxim Fomin via Digitalmars-d-learn]

On Saturday, 28 June 2014 at 20:40:21 UTC, Ary Borenszweig wrote:

This doesn't work:

class Foo {
  this() {
this = new Foo;
  }
}

Error: Cannot modify 'this'

However you can do this:

class Foo {
  this() {
auto p = this;
*p = new Foo();
  }
}

It even changes the value of this!

Should that compile? I mean, it's the same as modifying 
'this'...


D language was not aimed toward preventing any attepmt to 
circumvent some hypothetical limitations (it does not even cope 
with things which it should definetely prevent). There are holes 
much - much worse. And changing value of this parameter is not a 
problem anyway, since it is possible to have typeid(this) != 
typeid of type of current method which is bigger problem than 
pointing to different value of same type.