Which parts in dlang don't you use and why ?
Personally i have no need for enum types, immutable is doing fine.
Auto return types i find dangerous to use.
Voldermont types.
Named initialiser.
Tuple features.
Maybe some other ?
Feature creep can make your own code unreadable.
Offcourse taste can
On Saturday, 15 May 2021 at 14:31:08 UTC, Alain De Vos wrote:
Feature creep can make your own code unreadable.
Having many ways to express the same concept makes code harder to
read. This is an issue in C++, but you can combat it by creating
coding norms.
In general it is better to have few
I want to be able to support CP936, not just UTF8.
I can't use CP936. It's my pet peeve.
Hopefully we can solve the coding problem just like Python with
#encoding= GBK.
On Sat, May 15, 2021 at 02:31:08PM +, Alain De Vos via Digitalmars-d-learn
wrote:
> Which parts in dlang don't you use and why ?
>
> Personally i have no need for enum types, immutable is doing fine.
> Auto return types i find dangerous to use.
> Voldermont types.
> Named initialiser.
> Tuple
On Sunday, 16 May 2021 at 16:16:22 UTC, H. S. Teoh wrote:
I cannot live without auto return types and Voldemort types.
They are my bread and butter. Take them away, and I might as
well go back to C/C++.
C++ has both?
What I find ugly:
- shared, and all of its quirks and incomplete implementa
On Saturday, 15 May 2021 at 14:31:08 UTC, Alain De Vos wrote:
Which parts in dlang don't you use and why?
There is one feature (actually a mix of features) I'd be happy
not to use, but it is not possible: I call it autoreals, because
it resembles somewhat the idea behind autodecoding - in bot
Knowing the number of bytes in memory is a good thing.
For a number it's best to have something you know how many bytes
it takes in memory.
On Saturday, 15 May 2021 at 14:31:08 UTC, Alain De Vos wrote:
Which parts in dlang don't you use and why ?
Well, I don't like magic constructs in the language like the type
of AliasSeq you can't touch.
But the more general problem in D are not features per se, but
how they are composed of.
On Saturday, 22 May 2021 at 13:26:38 UTC, sighoya wrote:
But the more general problem in D are not features per se, but
how they are composed of.
For instance: Why no AST macros instead of string mixins,
templates, mixin templates and alias?
All these forms could be special ast macros.
I thin
On Saturday, 22 May 2021 at 13:31:45 UTC, Ola Fosheim Grøstad
wrote:
The D AST is not really suitable as it stands.
D is a bit like C++ in this regard, there might be a minimal
core language that could be distilled from it, but it would take
a D3 full breaking change to get there, so it won't
On Saturday, 22 May 2021 at 17:32:34 UTC, sighoya wrote:
But I think providing an external ast tree mapped onto the
changing internal one used by DMD would be a feasible approach.
It is feasible, but if you want to do it well you should think in
terms of rewrite engines with patternmatching, t
On Saturday, 15 May 2021 at 21:15:01 UTC, Ola Fosheim Grostad
wrote:
On Saturday, 15 May 2021 at 14:31:08 UTC, Alain De Vos wrote:
In general it is better to have fewer features and instead
improve metaprogramming so that missing features can be done in
a library.
Why is metaprogramming
On Sunday, 23 May 2021 at 08:35:31 UTC, Tony wrote:
Why is metaprogramming added features better than the same
features added in the language? One is standard between
entities, the other is not.
Some points:
- Some features aren't general enough to be added as builtin but
make sense to have t
On Sunday, 23 May 2021 at 08:35:31 UTC, Tony wrote:
On Saturday, 15 May 2021 at 21:15:01 UTC, Ola Fosheim Grostad
wrote:
Why is metaprogramming added features better than the same
features added in the language? One is standard between
entities, the other is not.
There are many reasons, one i
On Sunday, 23 May 2021 at 10:24:53 UTC, Ola Fosheim Grostad wrote:
On Sunday, 23 May 2021 at 08:35:31 UTC, Tony wrote:
On Saturday, 15 May 2021 at 21:15:01 UTC, Ola Fosheim Grostad
wrote:
Why is metaprogramming added features better than the same
features added in the language? One is standard
It is sufficient to have a bit complex gui and database access
and the @safe annotation can nowhere be used in your program.
The compiler misses scopes checks without.
On Sunday, 23 May 2021 at 12:08:31 UTC, Alain De Vos wrote:
It is sufficient to have a bit complex gui and database access
and the @safe annotation can nowhere be used in your program.
The compiler misses scopes checks without.
I think you are supposed to use @trusted to tell the compiler
tha
This one compiles without any problem.
Maybe someone can enlighten us on the status of
scope(d)-variables and dip-1000.
It is not fully clear for me.
```
import std.stdio;
void main() @trusted
{
int *q=null;
{
int a;
q=&a;
}
*q=5;
}
```
On Sunday, 23 May 2021 at 14:13:36 UTC, Alain De Vos wrote:
This one compiles without any problem.
You annotated main `@trusted`, which means you want the compiler
to assume it to be `@safe` without checking it. Mark it `@safe`
and it reports:
Error: address of variable `a` assigned to `q`
On Saturday, 15 May 2021 at 14:31:08 UTC, Alain De Vos wrote:
Which parts in dlang don't you use and why ?
Auto return types i find dangerous to use.
I found `auto` and `ref`(yes just `ref`) return types very useful
for bypassing the type system, eg.:
```D
///function requires lvalue and the
On Sunday, 23 May 2021 at 14:13:36 UTC, Alain De Vos wrote:
This one compiles without any problem.
Maybe someone can enlighten us on the status of
scope(d)-variables and dip-1000.
It is not fully clear for me.
```
import std.stdio;
void main() @trusted
{
int *q=null;
{
int a;
22 matches
Mail list logo