On Friday, 30 April 2021 at 13:05:00 UTC, Steven Schveighoffer
wrote:
On 4/29/21 1:50 PM, Meta wrote:
The reason for this, apparently, is in the definition of
`ifThrown`:
```
CommonType!(T1, T2) ifThrown(E : Throwable = Exception, T1,
T2)(lazy scope T1 expression, lazy scope T2
On 4/29/21 1:50 PM, Meta wrote:
The reason for this, apparently, is in the definition of `ifThrown`:
```
CommonType!(T1, T2) ifThrown(E : Throwable = Exception, T1, T2)(lazy
scope T1 expression, lazy scope T2 errorHandler) nothrow
```
It's not marked as `nothrow` in the function's
On Friday, 30 April 2021 at 01:30:54 UTC, Steven Schveighoffer
wrote:
In my case, for value of a certain type in the loop, I was
storing a specific field from the first one I found, and then
verifying that all the other values of that type (not exactly
the same type, but similar) had the
On 4/30/21 9:24 AM, sighoya wrote:
On Friday, 30 April 2021 at 01:30:54 UTC, Steven Schveighoffer wrote:
In my case, for value of a certain type in the loop, I was storing a
specific field from the first one I found, and then verifying that all
the other values of that type (not exactly the
On 4/30/21 9:24 AM, Meta wrote:
On Friday, 30 April 2021 at 13:05:00 UTC, Steven Schveighoffer wrote:
On 4/29/21 1:50 PM, Meta wrote:
The reason for this, apparently, is in the definition of `ifThrown`:
```
CommonType!(T1, T2) ifThrown(E : Throwable = Exception, T1, T2)(lazy
scope T1
On Friday, 30 April 2021 at 13:42:49 UTC, Steven Schveighoffer
wrote:
On 4/30/21 9:24 AM, Meta wrote:
My point is that I think marking the *function* nothrow is not
correct, it's the second parameter that dictates the throwing
of the result.
And you can probably fix the second parameter to
On Thursday, 29 April 2021 at 20:00:23 UTC, novice2 wrote:
i dont understand why (templates too dificult for me yet),
but if i comment "lazy" from T2,
then compiler allow add "nothrow" to "ifThrown"
```d
CommonType!(T1, T2) ifThrown(E : Throwable = Exception, T1,
T2)(lazy scope T1 expression,
On Wednesday, 28 April 2021 at 22:41:03 UTC, Alain De Vos wrote:
What are the strengths and weaknesses comparing the two
languages ?
I can name a strength of dlang is the working binding to tk and
gtk.
Pros of **Crystal**
1. Attractive syntax. I like Ruby like syntax. It's really
expressive.
tkd works perfectly. Which O.S. are you using ? I can guide.
On Thursday, 29 April 2021 at 22:47:08 UTC, Alain De Vos wrote:
What is the importance of type-annotations in which cases.
Specifying invariants which becomes very important when
refactoring code.
Further it aids as documentation to understand the structures
behind.
@X @Y @Z makes code
On Friday, 30 April 2021 at 13:36:10 UTC, Steven Schveighoffer
wrote:
I could have looped 2x over the args, and used an inner
function to fetch the first one (or maybe used a staticIndexOf
to get the first ColumnDef thing), and a second loop to verify
all the remaining args have the same table
On Friday, 30 April 2021 at 14:16:16 UTC, Vinod K Chandran wrote:
On Wednesday, 28 April 2021 at 22:41:03 UTC, Alain De Vos wrote:
What are the strengths and weaknesses comparing the two
languages ?
I can name a strength of dlang is the working binding to tk
and gtk.
Pros of **Crystal**
1.
An active maintainer is a living person, with a first name a last
name and an email adress, who looks into issues and tries to fix
them.
Now go look to this page ...
https://code.dlang.org/
Feel free to elaborate ...
dmd since 2.096.0 with ``t.d``
```t.d
module t;
class t {
}
```
and ``x.d``
```x.d
module x;
import t;
void main ()
{
t x = new t;
}
```
reports
$ dmd -i x.d
x.d(6): Error: import `x.t` is used as a type
x.d(6): Error: import `x.t` is used as a type
Could not find this
On Friday, 30 April 2021 at 17:33:19 UTC, Alain De Vos wrote:
An active maintainer is a living person, with a first name a
last name and an email adress, who looks into issues and tries
to fix them.
Now go look to this page ...
https://code.dlang.org/
Feel free to elaborate ...
I don't
Is there no room for improvement to discriminate between alive
and dead ? What do you think ?
Alive must fullfill these conditions in order to be referenced.
On Friday, 30 April 2021 at 17:58:43 UTC, kdevel wrote:
dmd since 2.096.0 with ``t.d``
```t.d
module t;
class t {
}
```
and ``x.d``
```x.d
module x;
import t;
void main ()
{
t x = new t;
}
```
reports
$ dmd -i x.d
x.d(6): Error: import `x.t` is used as a type
x.d(6): Error:
On Friday, 30 April 2021 at 18:27:02 UTC, Alain De Vos wrote:
Is there no room for improvement to discriminate between alive
and dead ? What do you think ?
Alive must fullfill these conditions in order to be referenced.
I and others think there's something wrong with the dub registry.
It has
On Friday, 30 April 2021 at 14:16:16 UTC, Vinod K Chandran wrote:
BTW, I wonder to see someone says that they have succeeded in
compiling a **tkD** example code. I tried it with no luck. So I
gave up that idea.
I did this @2014. No problems remembered.
https://dlang.org/spec/interfaceToC.html
On Friday, 30 April 2021 at 22:22:05 UTC, sfp wrote:
To be clear, I'm mostly interested in examples that show how to
structure a project. I'd like to know what the best way to
start using D in my current project is, how to call D from C,
and how to call C from D.
There is nothing
On Saturday, 1 May 2021 at 01:29:05 UTC, Mike Parker wrote:
As for the code, your main function should be `extern(C)`.
Functions you want to make available to the C side should also
be `extern(C)`, and will need equivalent declarations in C. DMD
has an experimental feature to generate C
On 26.04.21 21:13, WebFreak001 wrote:
On Monday, 26 April 2021 at 18:45:08 UTC, Christian Köstlin wrote:
Does anybody use serve-d with emacs (lsp-mode or eglot)?
I would love to see the configuration!
Kind regards,
Christian
if you configure it yourself, feel free to share the configuration
On Friday, 30 April 2021 at 22:22:05 UTC, sfp wrote:
I'm developing a C library with Cython bindings, built using
CMake. I'd like to use D with -betterC to write some new code
where it would be handy to have access to some more advanced
language features to keep things readable. For my domain,
I always thought as long as an object implements an interface, it
should be able to cast it from a void* if it really points to a
supporting object.
I have the similar structure:
```d
interface AI {
string doSomething();
}
template S() {
void foo() {
}
}
abstract class A : AI
On Friday, 30 April 2021 at 23:06:48 UTC, bachmeier wrote:
There is a blog series
https://dlang.org/blog/the-d-and-c-series/#betterC
Thanks for the link.
I read through these, but they don't address my question. The
first two posts are about specific -betterC features and the
third one is
On Friday, 30 April 2021 at 19:17:14 UTC, user1234 wrote:
[...]
Likely a side effect of https://github.com/dlang/dmd/pull/12178
but
according to me the new behavior is correct.
It breaks my code. I have files named $C containing struct or
class $C plus some other stuff. Using the workaround
I'm developing a C library with Cython bindings, built using
CMake. I'd like to use D with -betterC to write some new code
where it would be handy to have access to some more advanced
language features to keep things readable. For my domain, C is
totally fine 99% of the time, and rewriting a
28 matches
Mail list logo
