* follow #8463#14157 and document cstring literals
* Update doc/manual.rst
Co-authored-by: Juan Carlos <juancarlospaco@gmail.com>
Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
Make `requiresInit` pragma to work for distinct types in addition to
objects. Tagging of distinct types with `requiresInit` pragma was
already supported, but its impact wasn't applied. Now its behavior when
applied on distinct types is as follows.
Given the following distinct type definitions:
```nim
type
DistinctObject {.requiresInit, borrow: `.`.} = distinct MyObject
DistinctString {.requiresInit.} = distinct string
```
The following code blocks will fail to compile:
```nim
var foo: DistinctFoo
foo.x = "test"
doAssert foo.x == "test"
```
```nim
var s: DistinctString
s = "test"
doAssert s == "test"
```
But these ones will compile successfully:
```nim
let foo = DistinctFoo(Foo(x: "test"))
doAssert foo.x == "test"
```
```nim
let s = "test"
doAssert s == "test"
```
* implements https://github.com/nim-lang/RFCs/issues/258
* don't be too strict with custom pragma blocks
* cast pragmas: documentation
* added most missing inference query procs to effecttraits.nim
* spec for view types
* spec additions
* refactoring; there are two different kinds of views
* refactorings and spec additions
* enforce that view types are initialized
* enforce borrowing from the first formal parameter
* enforce lifetimes for borrowing of locals
* typo in the manual
* clarify in the implementation what a borrow operation really is
* I don't care about observable stores
* enforce explicit initializations
* cleaner code for the stdlib
* stdlib: use explicit initializations
* make tests green
* algorithm.nim: set result explicitly
* remove out parameters and bring the PR into a mergable state
* updated the changelog
Removed phrase "However, this is no real restriction because
Nim's syntax is flexible enough anyway." from the manual - I find it
very subjective, and I sometimes *do* find myself restricted by Nim's
syntax when writing DSLs
* Allow let to not have value when using importc
This allows a let statement with the `{.importc.}` pragma to not be
initialised with a value. This allows us to declare C constants as Nim
lets without putting the value in the Nim code (which can lead to
errors, and requires us to go looking for the value). Fixes#14253
* Proper fix and documentation + changelog entry
* Improve testcase with one from timotheecour
* Add test to verify it working with macros
`if expressions` are similar to ternary operators in other languages.
In order to make this easier to find in the manual, I've added a
sentence about it.
* do not track 'raise Defect' in the .raises: [] clause anymore
* --panics:on maps 'raise Defect' to an unrecoverable fatal error
* make tests green again
* update the documentation too
* Error -> Defect for defects
The distinction between Error and Defect is subjective,
context-dependent and somewhat arbitrary, so when looking at an
exception, it's hard to guess what it is - this happens often when
looking at a `raises` list _without_ opening the corresponding
definition and digging through layers of inheritance.
With the help of a little consistency in naming, it's at least possible
to start disentangling the two error types and the standard lib can set
a good example here.
